1. 29 10月, 2013 2 次提交
  2. 05 9月, 2013 2 次提交
    • N
      NFSv4: Don't try to recover NFSv4 locks when they are lost. · ef1820f9
      NeilBrown 提交于
      When an NFSv4 client loses contact with the server it can lose any
      locks that it holds.
      
      Currently when it reconnects to the server it simply tries to reclaim
      those locks.  This might succeed even though some other client has
      held and released a lock in the mean time.  So the first client might
      think the file is unchanged, but it isn't.  This isn't good.
      
      If, when recovery happens, the locks cannot be claimed because some
      other client still holds the lock, then we get a message in the kernel
      logs, but the client can still write.  So two clients can both think
      they have a lock and can both write at the same time.  This is equally
      not good.
      
      There was a patch a while ago
        http://comments.gmane.org/gmane.linux.nfs/41917
      
      which tried to address some of this, but it didn't seem to go
      anywhere.  That patch would also send a signal to the process.  That
      might be useful but for now this patch just causes writes to fail.
      
      For NFSv4 (unlike v2/v3) there is a strong link between the lock and
      the write request so we can fairly easily fail any IO of the lock is
      gone.  While some applications might not expect this, it is still
      safer than allowing the write to succeed.
      
      Because this is a fairly big change in behaviour a module parameter,
      "recover_locks", is introduced which defaults to true (the current
      behaviour) but can be set to "false" to tell the client not to try to
      recover things that were lost.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ef1820f9
    • C
      NFS: Fix warning introduced by NFSv4.0 transport blocking patches · b6a85258
      Chuck Lever 提交于
      When CONFIG_NFS_V4_1 is not enabled, gcc emits this warning:
      
      linux/fs/nfs/nfs4state.c:255:12: warning:
       ‘nfs4_begin_drain_session’ defined but not used [-Wunused-function]
       static int nfs4_begin_drain_session(struct nfs_client *clp)
                  ^
      
      Eventually NFSv4.0 migration recovery will invoke this function, but
      that has not yet been merged.  Hide nfs4_begin_drain_session()
      behind CONFIG_NFS_V4_1 for now.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b6a85258
  3. 04 9月, 2013 2 次提交
  4. 23 8月, 2013 1 次提交
    • N
      NFS: remove incorrect "Lock reclaim failed!" warning. · 6686390b
      NeilBrown 提交于
      After reclaiming state that was lost, the NFS client tries to reclaim
      any locks, and then checks that each one has NFS_LOCK_INITIALIZED set
      (which means that the server has confirmed the lock).
      However if the client holds a delegation, nfs_reclaim_locks() simply aborts
      (or more accurately it called nfs_lock_reclaim() and that returns without
      doing anything).
      
      This is because when a delegation is held, the server doesn't need to
      know about locks.
      
      So if a delegation is held, NFS_LOCK_INITIALIZED is not expected, and
      its absence is certainly not an error.
      
      So don't print the warnings if NFS_DELGATED_STATE is set.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6686390b
  5. 08 8月, 2013 2 次提交
    • C
      NFS: Never use user credentials for lease renewal · 73d8bde5
      Chuck Lever 提交于
      Never try to use a non-UID 0 user credential for lease management,
      as that credential can change out from under us.  The server will
      block NFSv4 lease recovery with NFS4ERR_CLID_INUSE.
      
      Since the mechanism to acquire a credential for lease management
      is now the same for all minor versions, replace the minor version-
      specific callout with a single function.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      73d8bde5
    • C
      NFS: Use root's credential for lease management when keytab is missing · d688f7b8
      Chuck Lever 提交于
      Commit 05f4c350 "NFS: Discover NFSv4 server trunking when mounting"
      Fri Sep 14 17:24:32 2012 introduced Uniform Client String support,
      which forces our NFS client to establish a client ID immediately
      during a mount operation rather than waiting until a user wants to
      open a file.
      
      Normally machine credentials (eg. from a keytab) are used to perform
      a mount operation that is protected by Kerberos.  Before 05fc350,
      SETCLIENTID used a machine credential, or fell back to a regular
      user's credential if no keytab is available.
      
      On clients that don't have a keytab, performing SETCLIENTID early
      means there's no user credential to fall back on, since no regular
      user has kinit'd yet.  05f4c350 seems to have broken the ability
      to mount with sec=krb5 on clients that don't have a keytab in
      kernels 3.7 - 3.10.
      
      To address this regression, commit 4edaa308 (NFS: Use "krb5i" to
      establish NFSv4 state whenever possible), Sat Mar 16 15:56:20 2013,
      was merged in 3.10.  This commit forces the NFS client to fall back
      to AUTH_SYS for lease management operations if no keytab is
      available.
      
      Neil Brown noticed that, since root is required to kinit to do a
      sec=krb5 mount when a client doesn't have a keytab, we can try to
      use root's Kerberos credential before AUTH_SYS.
      
      Now, when determining a principal and flavor to use for lease
      management, the NFS client tries in this order:
      
        1.  Flavor: AUTH_GSS, krb5i
            Principal: service principal (via keytab)
      
        2.  Flavor: AUTH_GSS, krb5i
            Principal: user principal established for UID 0 (via kinit)
      
        3.  Flavor: AUTH_SYS
            Principal: UID 0 / GID 0
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      d688f7b8
  6. 24 7月, 2013 1 次提交
  7. 04 7月, 2013 1 次提交
  8. 29 6月, 2013 1 次提交
    • J
      locks: protect most of the file_lock handling with i_lock · 1c8c601a
      Jeff Layton 提交于
      Having a global lock that protects all of this code is a clear
      scalability problem. Instead of doing that, move most of the code to be
      protected by the i_lock instead. The exceptions are the global lists
      that the ->fl_link sits on, and the ->fl_block list.
      
      ->fl_link is what connects these structures to the
      global lists, so we must ensure that we hold those locks when iterating
      over or updating these lists.
      
      Furthermore, sound deadlock detection requires that we hold the
      blocked_list state steady while checking for loops. We also must ensure
      that the search and update to the list are atomic.
      
      For the checking and insertion side of the blocked_list, push the
      acquisition of the global lock into __posix_lock_file and ensure that
      checking and update of the  blocked_list is done without dropping the
      lock in between.
      
      On the removal side, when waking up blocked lock waiters, take the
      global lock before walking the blocked list and dequeue the waiters from
      the global list prior to removal from the fl_block list.
      
      With this, deadlock detection should be race free while we minimize
      excessive file_lock_lock thrashing.
      
      Finally, in order to avoid a lock inversion problem when handling
      /proc/locks output we must ensure that manipulations of the fl_block
      list are also protected by the file_lock_lock.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1c8c601a
  9. 20 6月, 2013 1 次提交
  10. 07 6月, 2013 1 次提交
  11. 21 5月, 2013 1 次提交
    • A
      NFSv4.1 Fix a pNFS session draining deadlock · 774d5f14
      Andy Adamson 提交于
      On a CB_RECALL the callback service thread flushes the inode using
      filemap_flush prior to scheduling the state manager thread to return the
      delegation. When pNFS is used and I/O has not yet gone to the data server
      servicing the inode, a LAYOUTGET can preceed the I/O. Unlike the async
      filemap_flush call, the LAYOUTGET must proceed to completion.
      
      If the state manager starts to recover data while the inode flush is sending
      the LAYOUTGET, a deadlock occurs as the callback service thread holds the
      single callback session slot until the flushing is done which blocks the state
      manager thread, and the state manager thread has set the session draining bit
      which puts the inode flush LAYOUTGET RPC to sleep on the forechannel slot
      table waitq.
      
      Separate the draining of the back channel from the draining of the fore channel
      by moving the NFS4_SESSION_DRAINING bit from session scope into the fore
      and back slot tables.  Drain the back channel first allowing the LAYOUTGET
      call to proceed (and fail) so the callback service thread frees the callback
      slot. Then proceed with draining the forechannel.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      774d5f14
  12. 07 5月, 2013 1 次提交
  13. 23 4月, 2013 1 次提交
    • C
      NFS: Retry SETCLIENTID with AUTH_SYS instead of AUTH_NONE · 79d852bf
      Chuck Lever 提交于
      Recently I changed the SETCLIENTID code to use AUTH_GSS(krb5i), and
      then retry with AUTH_NONE if that didn't work.  This was to enable
      Kerberos NFS mounts to work without forcing Linux NFS clients to
      have a keytab on hand.
      
      Rick Macklem reports that the FreeBSD server accepts AUTH_NONE only
      for NULL operations (thus certainly not for SETCLIENTID).  Falling
      back to AUTH_NONE means our proposed 3.10 NFS client will not
      interoperate with FreeBSD servers over NFSv4 unless Kerberos is
      fully configured on both ends.
      
      If the Linux client falls back to using AUTH_SYS instead for
      SETCLIENTID, all should work fine as long as the NFS server is
      configured to allow AUTH_SYS for SETCLIENTID.
      
      This may still prevent access to Kerberos-only FreeBSD servers by
      Linux clients with no keytab.  Rick is of the opinion that the
      security settings the server applies to its pseudo-fs should also
      apply to the SETCLIENTID operation.
      
      Linux and Solaris NFS servers do not place that limitation on
      SETCLIENTID.  The security settings for the server's pseudo-fs are
      determined automatically as the union of security flavors allowed on
      real exports, as recommended by RFC 3530bis; and the flavors allowed
      for SETCLIENTID are all flavors supported by the respective server
      implementation.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      79d852bf
  14. 20 4月, 2013 1 次提交
  15. 09 4月, 2013 1 次提交
    • T
      NFSv4: Handle timeouts correctly when probing for lease validity · bc7a05ca
      Trond Myklebust 提交于
      When we send a RENEW or SEQUENCE operation in order to probe if the
      lease is still valid, we want it to be able to time out since the
      lease we are probing is likely to time out too. Currently, because
      we use soft mount semantics for these RPC calls, the return value
      is EIO, which causes the state manager to exit with an "unhandled
      error" message.
      This patch changes the call semantics, so that the RPC layer returns
      ETIMEDOUT instead of EIO. We then have the state manager default to
      a simple retry instead of exiting.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bc7a05ca
  16. 06 4月, 2013 3 次提交
  17. 30 3月, 2013 1 次提交
    • C
      NFS: Use "krb5i" to establish NFSv4 state whenever possible · 4edaa308
      Chuck Lever 提交于
      Currently our client uses AUTH_UNIX for state management on Kerberos
      NFS mounts in some cases.  For example, if the first mount of a
      server specifies "sec=sys," the SETCLIENTID operation is performed
      with AUTH_UNIX.  Subsequent mounts using stronger security flavors
      can not change the flavor used for lease establishment.  This might
      be less security than an administrator was expecting.
      
      Dave Noveck's migration issues draft recommends the use of an
      integrity-protecting security flavor for the SETCLIENTID operation.
      Let's ignore the mount's sec= setting and use krb5i as the default
      security flavor for SETCLIENTID.
      
      If our client can't establish a GSS context (eg. because it doesn't
      have a keytab or the server doesn't support Kerberos) we fall back
      to using AUTH_NULL.  For an operation that requires a
      machine credential (which never represents a particular user)
      AUTH_NULL is as secure as AUTH_UNIX.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      4edaa308
  18. 29 3月, 2013 1 次提交
  19. 26 3月, 2013 4 次提交
  20. 12 2月, 2013 2 次提交
  21. 31 1月, 2013 1 次提交
  22. 28 1月, 2013 1 次提交
  23. 13 12月, 2012 2 次提交
    • Y
      nfs: Remove unused list nfs4_clientid_list · 48d7a576
      Yanchuan Nian 提交于
      This list was designed to store struct nfs4_client in the client side.
      But nfs4_client was obsolete and has been removed from the source code.
      So remove the unused list.
      Signed-off-by: NYanchuan Nian <ycnian@gmail.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      48d7a576
    • A
      SUNRPC handle EKEYEXPIRED in call_refreshresult · eb96d5c9
      Andy Adamson 提交于
      Currently, when an RPCSEC_GSS context has expired or is non-existent
      and the users (Kerberos) credentials have also expired or are non-existent,
      the client receives the -EKEYEXPIRED error and tries to refresh the context
      forever.  If an application is performing I/O, or other work against the share,
      the application hangs, and the user is not prompted to refresh/establish their
      credentials. This can result in a denial of service for other users.
      
      Users are expected to manage their Kerberos credential lifetimes to mitigate
      this issue.
      
      Move the -EKEYEXPIRED handling into the RPC layer. Try tk_cred_retry number
      of times to refresh the gss_context, and then return -EACCES to the application.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      eb96d5c9
  24. 06 12月, 2012 6 次提交