1. 03 1月, 2019 1 次提交
  2. 20 12月, 2018 4 次提交
    • N
      NFS/NFSD/SUNRPC: replace generic creds with 'struct cred'. · a52458b4
      NeilBrown 提交于
      SUNRPC has two sorts of credentials, both of which appear as
      "struct rpc_cred".
      There are "generic credentials" which are supplied by clients
      such as NFS and passed in 'struct rpc_message' to indicate
      which user should be used to authorize the request, and there
      are low-level credentials such as AUTH_NULL, AUTH_UNIX, AUTH_GSS
      which describe the credential to be sent over the wires.
      
      This patch replaces all the generic credentials by 'struct cred'
      pointers - the credential structure used throughout Linux.
      
      For machine credentials, there is a special 'struct cred *' pointer
      which is statically allocated and recognized where needed as
      having a special meaning.  A look-up of a low-level cred will
      map this to a machine credential.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Acked-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a52458b4
    • N
      NFS/SUNRPC: don't lookup machine credential until rpcauth_bindcred(). · 5e16923b
      NeilBrown 提交于
      When NFS creates a machine credential, it is a "generic" credential,
      not tied to any auth protocol, and is really just a container for
      the princpal name.
      This doesn't get linked to a genuine credential until rpcauth_bindcred()
      is called.
      The lookup always succeeds, so various places that test if the machine
      credential is NULL, are pointless.
      
      As a step towards getting rid of generic credentials, this patch gets
      rid of generic machine credentials.  The nfs_client and rpc_client
      just hold a pointer to a constant principal name.
      When a machine credential is wanted, a special static 'struct rpc_cred'
      pointer is used. rpcauth_bindcred() recognizes this, finds the
      principal from the client, and binds the correct credential.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      5e16923b
    • N
      NFSv4: don't require lock for get_renew_cred or get_machine_cred · f15e1e8b
      NeilBrown 提交于
      This lock is no longer necessary.
      
      If nfs4_get_renew_cred() needs to hunt through the open-state
      creds for a user cred, it still takes the lock to stablize
      the rbtree, but otherwise there are no races.
      
      Note that this completely removes the lock from nfs4_renew_state().
      It appears that the original need for the locking here was removed
      long ago, and there is no longer anything to protect.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      f15e1e8b
    • N
      NFSv4: add cl_root_cred for use when machine cred is not available. · a534ecb0
      NeilBrown 提交于
      NFSv4 state management tries a root credential when no machine
      credential is available, as can happen with kerberos.
      It does this by replacing the cl_machine_cred with a root credential.
      This means that any user of the machine credential needs to take
      a lock while getting a reference to the machine credential, which is
      a little cumbersome.
      
      So introduce an explicit cl_root_cred, and never free either
      credential until client shutdown.  This means that no locking
      is needed to reference these credentials.  Future patches
      will make use of this.
      
      This is only a temporary addition.  both cl_machine_cred and
      cl_root_cred will disappear later in the series.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a534ecb0
  3. 20 11月, 2018 1 次提交
  4. 13 11月, 2018 2 次提交
  5. 01 10月, 2018 7 次提交
  6. 15 9月, 2018 1 次提交
    • 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
  7. 14 8月, 2018 2 次提交
  8. 09 8月, 2018 1 次提交
  9. 01 6月, 2018 1 次提交
  10. 11 4月, 2018 1 次提交
  11. 15 1月, 2018 1 次提交
    • N
      NFSv4: always set NFS_LOCK_LOST when a lock is lost. · dce2630c
      NeilBrown 提交于
      There are 2 comments in the NFSv4 code which suggest that
      SIGLOST should possibly be sent to a process.  In these
      cases a lock has been lost.
      The current practice is to set NFS_LOCK_LOST so that
      read/write returns EIO when a lock is lost.
      So change these comments to code when sets NFS_LOCK_LOST.
      
      One case is when lock recovery after apparent server restart
      fails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or
      NFS4ERRO_RECLAIM_CONFLICT.  The other case is when a lock
      attempt as part of lease recovery fails with NFS4ERR_DENIED.
      
      In an ideal world, these should not happen.  However I have
      a packet trace showing an NFSv4.1 session getting
      NFS4ERR_BADSESSION after an extended network parition.  The
      NFSv4.1 client treats this like server reboot until/unless
      it get NFS4ERR_NO_GRACE, in which case it switches over to
      "nograce" recovery mode.  In this network trace, the client
      attempts to recover a lock and the server (incorrectly)
      reports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE.  This
      leads to the ineffective comment and the client then
      continues to write using the OPEN stateid.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      dce2630c
  12. 30 11月, 2017 1 次提交
  13. 18 11月, 2017 7 次提交
  14. 14 7月, 2017 1 次提交
    • C
      NFSv4.1: Handle EXCHGID4_FLAG_CONFIRMED_R during NFSv4.1 migration · 8dcbec6d
      Chuck Lever 提交于
      Transparent State Migration copies a client's lease state from the
      server where a filesystem used to reside to the server where it now
      resides. When an NFSv4.1 client first contacts that destination
      server, it uses EXCHANGE_ID to detect trunking relationships.
      
      The lease that was copied there is returned to that client, but the
      destination server sets EXCHGID4_FLAG_CONFIRMED_R when replying to
      the client. This is because the lease was confirmed on the source
      server (before it was copied).
      
      Normally, when CONFIRMED_R is set, a client purges the lease and
      creates a new one. However, that throws away the entire benefit of
      Transparent State Migration.
      
      Therefore, the client must not purge that lease when it is possible
      that Transparent State Migration has occurred.
      Reported-by: NXuan Qi <xuan.qi@oracle.com>
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Tested-by: NXuan Qi <xuan.qi@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      8dcbec6d
  15. 28 6月, 2017 1 次提交
  16. 06 5月, 2017 1 次提交
  17. 31 1月, 2017 1 次提交
  18. 27 1月, 2017 1 次提交
  19. 14 1月, 2017 1 次提交
  20. 20 12月, 2016 2 次提交
    • N
      NFS: Don't disconnect open-owner on NFS4ERR_BAD_SEQID · 86cfb041
      NeilBrown 提交于
      When an NFS4ERR_BAD_SEQID is received the open-owner is removed from
      the ->state_owners rbtree so that it will no longer be used.
      
      If any stateids attached to this open-owner are still in use, and if a
      request using one gets an NFS4ERR_BAD_STATEID reply, this can for bad.
      
      The state is marked as needing recovery and the nfs4_state_manager()
      is scheduled to clean up.  nfs4_state_manager() finds states to be
      recovered by walking the state_owners rbtree.  As the open-owner is
      not in the rbtree, the bad state is not found so nfs4_state_manager()
      completes having done nothing.  The request is then retried, with a
      predicatable result (indefinite retries).
      
      If the stateid is for a delegation, this open_owner will be used
      to open files when the delegation is returned.  For that to work,
      a new open-owner needs to be presented to the server.
      
      This patch changes NFS4ERR_BAD_SEQID handling to leave the open-owner
      in the rbtree but updates the 'create_time' so it looks like a new
      open-owner.  With this the indefinite retries no longer happen.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      86cfb041
    • N
      NFSv4: ensure __nfs4_find_lock_state returns consistent result. · 3f8f2548
      NeilBrown 提交于
      If a file has both flock locks and OFD locks, then it is possible that
      two different nfs4 lock states could apply to file accesses from a
      single process.
      
      It is not possible to know, efficiently, which one is "correct".
      Presumably the state which represents a lock that covers the region
      undergoing IO would be the "correct" one to use, but finding that has
      a non-trivial cost and would provide miniscule value.
      
      Currently we just return whichever is first in the list, which could
      result in inconsistent behaviour if an application ever put it self in
      this position.  As consistent behaviour is preferable (when perfectly
      correct behaviour is not available), change the search to return a
      consistent result in this circumstance.
      Specifically: if there is both a flock and OFD lock state, always return
      the flock one.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      3f8f2548
  21. 05 12月, 2016 1 次提交
  22. 02 12月, 2016 1 次提交