1. 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
  2. 07 5月, 2013 1 次提交
  3. 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
  4. 20 4月, 2013 1 次提交
  5. 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
  6. 06 4月, 2013 3 次提交
  7. 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
  8. 29 3月, 2013 1 次提交
  9. 26 3月, 2013 4 次提交
  10. 12 2月, 2013 2 次提交
  11. 31 1月, 2013 1 次提交
  12. 28 1月, 2013 1 次提交
  13. 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
  14. 06 12月, 2012 11 次提交
  15. 27 11月, 2012 1 次提交
  16. 21 11月, 2012 2 次提交
  17. 05 11月, 2012 1 次提交
  18. 03 10月, 2012 1 次提交
  19. 02 10月, 2012 4 次提交
    • A
      NFSv4.0 reclaim reboot state when re-establishing clientid · 47b803c8
      Andy Adamson 提交于
      We should reclaim reboot state when the clientid is stale.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      47b803c8
    • T
      NFSv4: Fix up a merge conflict between migration and container changes · 9f62387d
      Trond Myklebust 提交于
      nfs_callback_tcpport is now per-net_namespace.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      9f62387d
    • C
      NFS: Discover NFSv4 server trunking when mounting · 05f4c350
      Chuck Lever 提交于
      "Server trunking" is a fancy named for a multi-homed NFS server.
      Trunking might occur if a client sends NFS requests for a single
      workload to multiple network interfaces on the same server.  There
      are some implications for NFSv4 state management that make it useful
      for a client to know if a single NFSv4 server instance is
      multi-homed.  (Note this is only a consideration for NFSv4, not for
      legacy versions of NFS, which are stateless).
      
      If a client cares about server trunking, no NFSv4 operations can
      proceed until that client determines who it is talking to.  Thus
      server IP trunking discovery must be done when the client first
      encounters an unfamiliar server IP address.
      
      The nfs_get_client() function walks the nfs_client_list and matches
      on server IP address.  The outcome of that walk tells us immediately
      if we have an unfamiliar server IP address.  It invokes
      nfs_init_client() in this case.  Thus, nfs4_init_client() is a good
      spot to perform trunking discovery.
      
      Discovery requires a client to establish a fresh client ID, so our
      client will now send SETCLIENTID or EXCHANGE_ID as the first NFS
      operation after a successful ping, rather than waiting for an
      application to perform an operation that requires NFSv4 state.
      
      The exact process for detecting trunking is different for NFSv4.0 and
      NFSv4.1, so a minorversion-specific init_client callout method is
      introduced.
      
      CLID_INUSE recovery is important for the trunking discovery process.
      CLID_INUSE is a sign the server recognizes the client's nfs_client_id4
      id string, but the client is using the wrong principal this time for
      the SETCLIENTID operation.  The SETCLIENTID must be retried with a
      series of different principals until one works, and then the rest of
      trunking discovery can proceed.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      05f4c350
    • C
      NFS: Slow down state manager after an unhandled error · ffe5a830
      Chuck Lever 提交于
      If the state manager thread is not actually able to fully recover from
      some situation, it wakes up waiters, who kick off a new state manager
      thread.  Quite often the fresh invocation of the state manager is just
      as successful.
      
      This results in a livelock as the client dumps thousands of NFS
      requests a second on the network in a vain attempt to recover.  Not
      very friendly.
      
      To mitigate this situation, add a delay in the state manager after
      an unhandled error, so that the client sends just a few requests
      every second in this case.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      ffe5a830