1. 15 5月, 2019 1 次提交
  2. 03 4月, 2019 1 次提交
  3. 24 3月, 2019 1 次提交
  4. 15 9月, 2018 2 次提交
    • T
      NFS: Don't open code clearing of delegation state · 9f0c5124
      Trond Myklebust 提交于
      Add a helper for the case when the nfs4 open state has been set to use
      a delegation stateid, and we want to revert to using the open stateid.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      9f0c5124
    • T
      NFSv4.1 fix infinite loop on I/O. · 994b15b9
      Trond Myklebust 提交于
      The previous fix broke recovery of delegated stateids because it assumes
      that if we did not mark the delegation as suspect, then the delegation has
      effectively been revoked, and so it removes that delegation irrespectively
      of whether or not it is valid and still in use. While this is "mostly
      harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning
      in an infinite loop while complaining that we're using an invalid stateid
      (in this case the all-zero stateid).
      
      What we rather want to do here is ensure that the delegation is always
      correctly marked as needing testing when that is the case. So we want
      to close the loophole offered by nfs4_schedule_stateid_recovery(),
      which marks the state as needing to be reclaimed, but not the
      delegation that may be backing it.
      
      Fixes: 0e3d3e5d ("NFSv4.1 fix infinite loop on IO BAD_STATEID error")
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Cc: stable@vger.kernel.org # v4.11+
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      994b15b9
  5. 17 8月, 2018 1 次提交
  6. 14 8月, 2018 1 次提交
  7. 10 8月, 2018 3 次提交
  8. 09 8月, 2018 6 次提交
  9. 02 8月, 2018 1 次提交
    • T
      NFSv4: Fix _nfs4_do_setlk() · 6ea76bf5
      Trond Myklebust 提交于
      The patch to fix the case where a lock request was interrupted ended up
      changing default handling of errors such as NFS4ERR_DENIED and caused the
      client to immediately resend the lock request. Let's do a partial revert
      of that request so that the default is now to exit, but change the way
      we handle resends to take into account the fact that the user may have
      interrupted the request.
      Reported-by: NKenneth Johansson <ken@kenjo.org>
      Fixes: a3cf9bca ("NFSv4: Don't add a new lock on an interrupted wait..")
      Cc: Benjamin Coddington <bcodding@redhat.com>
      Cc: Jeff Layton <jlayton@kernel.org>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      Reviewed-by: NJeff Layton <jlayton@kernel.org>
      6ea76bf5
  10. 01 8月, 2018 1 次提交
    • B
      NFSv4 client live hangs after live data migration recovery · 0f90be13
      Bill Baker 提交于
      After a live data migration event at the NFS server, the client may send
      I/O requests to the wrong server, causing a live hang due to repeated
      recovery events.  On the wire, this will appear as an I/O request failing
      with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly.
      NFS4ERR_BADSSESSION is returned because the session ID being used was
      issued by the other server and is not valid at the old server.
      
      The failure is caused by async worker threads having cached the transport
      (xprt) in the rpc_task structure.  After the migration recovery completes,
      the task is redispatched and the task resends the request to the wrong
      server based on the old value still present in tk_xprt.
      
      The solution is to recompute the tk_xprt field of the rpc_task structure
      so that the request goes to the correct server.
      Signed-off-by: NBill Baker <bill.baker@oracle.com>
      Reviewed-by: NChuck Lever <chuck.lever@oracle.com>
      Tested-by: NHelen Chao <helen.chao@oracle.com>
      Fixes: fb43d172 ("SUNRPC: Use the multipath iterator to assign a ...")
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      0f90be13
  11. 31 7月, 2018 1 次提交
  12. 27 7月, 2018 1 次提交
  13. 12 7月, 2018 1 次提交
    • A
      introduce FMODE_CREATED and switch to it · 73a09dd9
      Al Viro 提交于
      Parallel to FILE_CREATED, goes into ->f_mode instead of *opened.
      NFS is a bit of a wart here - it doesn't have file at the point
      where FILE_CREATED used to be set, so we need to propagate it
      there (for now).  IMA is another one (here and everywhere)...
      
      Note that this needs do_dentry_open() to leave old bits in ->f_mode
      alone - we want it to preserve FMODE_CREATED if it had been already
      set (no other bit can be there).
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      73a09dd9
  14. 19 6月, 2018 2 次提交
  15. 10 6月, 2018 2 次提交
  16. 06 6月, 2018 2 次提交
    • C
      NFSv4.0: Remove transport protocol name from non-UCS client ID · 025bb9f8
      Chuck Lever 提交于
      Commit 69dd716c ("NFSv4: Add socket proto argument to
      setclientid") (2007) added the transport protocol name to the client
      ID string, but the patch description doesn't explain why this was
      necessary.
      
      At that time, the only transport protocol name that would have been
      used is "tcp" (for both IPv4 and IPv6), resulting in no additional
      distinctiveness of the client ID string.
      
      Since there is one client instance, the server should recognize it's
      state whether the client is connecting via TCP or RDMA. Same client,
      same lease.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      025bb9f8
    • C
      NFSv4.0: Remove cl_ipaddr from non-UCS client ID · 848a4eb2
      Chuck Lever 提交于
      It is possible for two distinct clients to have the same cl_ipaddr:
      
       - if the client admin disables callback with clientaddr=0.0.0.0 on
         more than one client
      
       - if two clients behind separate NATs use the same private subnet
         number
      
       - if the client admin specifies the same address via clientaddr=
         mount option (pointing the server at the same NAT box, for
         example)
      
      Because of the way the Linux NFSv4.0 client constructs its client
      ID string by default, such clients could interfere with each others'
      lease state when mounting the same server:
      
      	scnprintf(str, len, "Linux NFSv4.0 %s/%s %s",
      		clp->cl_ipaddr,
      		rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_ADDR),
      		rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_PROTO));
      
      cl_ipaddr is set to the value of the clientaddr= mount option. Two
      clients whose addresses are 192.168.3.77 that mount the same server
      (whose public IP address is, say, 3.4.5.6) would both generate the
      same client ID string when sending a SETCLIENTID:
      
        Linux NFSv4.0 192.168.3.77/3.4.5.6 tcp
      
      and thus the server would not be able to distinguish the clients'
      leases. If both clients are using AUTH_SYS when sending SETCLIENTID
      then the server could possibly permit the two clients to interfere
      with or purge each others' leases.
      
      To better ensure that Linux's NFSv4.0 client ID strings are distinct
      in these cases, remove cl_ipaddr from the client ID string and
      replace it with something more likely to be unique. Note that the
      replacement looks a lot like the uniform client ID string.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      848a4eb2
  17. 05 6月, 2018 6 次提交
  18. 01 6月, 2018 7 次提交