Skip to content
Snippets Groups Projects
  1. Jun 06, 2013
  2. May 20, 2013
    • Andy Adamson's avatar
      NFSv4.1 Fix a pNFS session draining deadlock · 774d5f14
      Andy Adamson authored
      
      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: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      774d5f14
  3. May 06, 2013
  4. Apr 22, 2013
    • Chuck Lever's avatar
      NFS: Retry SETCLIENTID with AUTH_SYS instead of AUTH_NONE · 79d852bf
      Chuck Lever authored
      
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      79d852bf
  5. Apr 20, 2013
  6. Apr 09, 2013
    • Trond Myklebust's avatar
      NFSv4: Handle timeouts correctly when probing for lease validity · bc7a05ca
      Trond Myklebust authored
      
      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: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      bc7a05ca
  7. Apr 05, 2013
  8. Mar 29, 2013
    • Chuck Lever's avatar
      NFS: Use "krb5i" to establish NFSv4 state whenever possible · 4edaa308
      Chuck Lever authored
      
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4edaa308
  9. Mar 28, 2013
  10. Mar 25, 2013
  11. Feb 11, 2013
  12. Jan 30, 2013
  13. Jan 27, 2013
  14. Dec 13, 2012
  15. Dec 12, 2012
    • Andy Adamson's avatar
      SUNRPC handle EKEYEXPIRED in call_refreshresult · eb96d5c9
      Andy Adamson authored
      
      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: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      eb96d5c9
  16. Dec 06, 2012
  17. Nov 26, 2012
  18. Nov 21, 2012
  19. Nov 04, 2012
  20. Oct 02, 2012
    • Weston Andros Adamson's avatar
      NFSv4.1: don't do two EXCHANGE_IDs on mount · fd483570
      Weston Andros Adamson authored
      
      Since the addition of NFSv4 server trunking detection the mount context
      calls nfs4_proc_exchange_id then schedules the state manager, which also
      calls nfs4_proc_exchange_id. Setting the NFS4CLNT_LEASE_CONFIRM bit
      makes the state manager skip the unneeded EXCHANGE_ID and continue on
      with session creation.
      
      Reported-by: default avatarJorge Mora <mora@netapp.com>
      Signed-off-by: default avatarWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      fd483570
    • Andy Adamson's avatar
      NFSv4.0 reclaim reboot state when re-establishing clientid · 47b803c8
      Andy Adamson authored
      
      We should reclaim reboot state when the clientid is stale.
      
      Signed-off-by: default avatarAndy Adamson <andros@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      47b803c8
    • Trond Myklebust's avatar
      NFSv4: Fix up a merge conflict between migration and container changes · 9f62387d
      Trond Myklebust authored
      
      nfs_callback_tcpport is now per-net_namespace.
      
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      9f62387d
    • Chuck Lever's avatar
      NFS: Discover NFSv4 server trunking when mounting · 05f4c350
      Chuck Lever authored
      
      "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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      05f4c350
Loading