1. 29 10月, 2013 5 次提交
  2. 02 10月, 2013 1 次提交
  3. 08 9月, 2013 2 次提交
  4. 07 9月, 2013 1 次提交
    • A
      NFSv4.1 Use MDS auth flavor for data server connection · 0e20162e
      Andy Adamson 提交于
      Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
      uses the nfs_client cl_rpcclient for all state management operations, and
      will use krb5i or auth_sys with no regard to the mount command authflavor
      choice.
      
      The MDS, as any NFSv4.1 mount point, uses the nfs_server rpc client for all
      non-state management operations with a different nfs_server for each fsid
      encountered traversing the mount point, each with a potentially different
      auth flavor.
      
      pNFS data servers are not mounted in the normal sense as there is no associated
      nfs_server structure. Data servers can also export multiple fsids, each with
      a potentially different auth flavor.
      
      Data servers need to use the same authflavor as the MDS server rpc client for
      non-state management operations. Populate a list of rpc clients with the MDS
      server rpc client auth flavor for the DS to use.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0e20162e
  5. 04 9月, 2013 1 次提交
  6. 08 8月, 2013 1 次提交
  7. 29 6月, 2013 2 次提交
  8. 09 6月, 2013 2 次提交
  9. 24 5月, 2013 1 次提交
  10. 15 4月, 2013 1 次提交
  11. 11 4月, 2013 1 次提交
  12. 06 4月, 2013 1 次提交
    • T
      NFSv4/4.1: Fix bugs in nfs4[01]_walk_client_list · 7b1f1fd1
      Trond Myklebust 提交于
      It is unsafe to use list_for_each_entry_safe() here, because
      when we drop the nn->nfs_client_lock, we pin the _current_ list
      entry and ensure that it stays in the list, but we don't do the
      same for the _next_ list entry. Use of list_for_each_entry() is
      therefore the correct thing to do.
      
      Also fix the refcounting in nfs41_walk_client_list().
      
      Finally, ensure that the nfs_client has finished being initialised
      and, in the case of NFSv4.1, that the session is set up.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Cc: stable@vger.kernel.org [>= 3.7]
      7b1f1fd1
  13. 05 4月, 2013 1 次提交
  14. 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
  15. 26 3月, 2013 1 次提交
  16. 28 2月, 2013 1 次提交
  17. 05 2月, 2013 1 次提交
  18. 28 1月, 2013 3 次提交
  19. 06 12月, 2012 1 次提交
  20. 05 11月, 2012 1 次提交
  21. 03 10月, 2012 1 次提交
  22. 02 10月, 2012 4 次提交
    • T
      NFSv4: nfs4_match_clientids is only used by NFSv4.1 · f9d640f3
      Trond Myklebust 提交于
      Fix another compiler warning.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f9d640f3
    • 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
    • S
      NFS: move per-net callback thread initialization to nfs_callback_up_net() · c946556b
      Stanislav Kinsbursky 提交于
      v4:
      1) Callback transport creation routine selection by version simlified.
      
      This new function in now called before nfs_minorversion_callback_svc_setup()).
      
      Also few small changes:
      1) current network namespace in nfs_callback_up() was replaced by transport net.
      2) svc_shutdown_net() was moved prior to callback usage counter decrement
      (because in case of per-net data allocation faulure svc_shutdown_net() have to
      be skipped).
      Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c946556b
    • S
  23. 21 8月, 2012 1 次提交
  24. 31 7月, 2012 3 次提交
  25. 18 7月, 2012 2 次提交