1. 23 5月, 2012 2 次提交
    • C
      NFS: EXCHANGE_ID should save the server major and minor ID · acdeb69d
      Chuck Lever 提交于
      Save the server major and minor ID results from EXCHANGE_ID, as they
      are needed for detecting server trunking.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      acdeb69d
    • C
      NFS: Always use the same SETCLIENTID boot verifier · f092075d
      Chuck Lever 提交于
      Currently our NFS client assigns a unique SETCLIENTID boot verifier
      for each server IP address it knows about.  It's set to CURRENT_TIME
      when the struct nfs_client for that server IP is created.
      
      During the SETCLIENTID operation, our client also presents an
      nfs_client_id4 string to servers, as an identifier on which the server
      can hang all of this client's NFSv4 state.  Our client's
      nfs_client_id4 string is unique for each server IP address.
      
      An NFSv4 server is obligated to wipe all NFSv4 state associated with
      an nfs_client_id4 string when the client presents the same
      nfs_client_id4 string along with a changed SETCLIENTID boot verifier.
      
      When our client unmounts the last of a server's shares, it destroys
      that server's struct nfs_client.  The next time the client mounts that
      NFS server, it creates a fresh struct nfs_client with a fresh boot
      verifier.  On seeing the fresh verifer, the server wipes any previous
      NFSv4 state associated with that nfs_client_id4.
      
      However, NFSv4.1 clients are supposed to present the same
      nfs_client_id4 string to all servers.  And, to support Transparent
      State Migration, the same nfs_client_id4 string should be presented
      to all NFSv4.0 servers so they recognize that migrated state for this
      client belongs with state a server may already have for this client.
      (This is known as the Uniform Client String model).
      
      If the nfs_client_id4 string is the same but the boot verifier changes
      for each server IP address, SETCLIENTID and EXCHANGE_ID operations
      from such a client could unintentionally result in a server wiping a
      client's previously obtained lease.
      
      Thus, if our NFS client is going to use a fixed nfs_client_id4 string,
      either for NFSv4.0 or NFSv4.1 mounts, our NFS client should use a
      boot verifier that does not change depending on server IP address.
      Replace our current per-nfs_client boot verifier with a per-nfs_net
      boot verifier.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f092075d
  2. 02 5月, 2012 6 次提交
  3. 28 4月, 2012 5 次提交
  4. 21 4月, 2012 1 次提交
  5. 15 3月, 2012 1 次提交
  6. 09 3月, 2012 1 次提交
  7. 06 3月, 2012 12 次提交
  8. 03 3月, 2012 5 次提交
    • C
      NFS: Reduce debugging noise from encode_compound_hdr · 54b50af0
      Chuck Lever 提交于
      Get rid of
      
        encode_compound: tag=
      
      when XDR debugging is enabled.  The current Linux client never sets
      compound tags.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      54b50af0
    • C
      NFS: Request fh_expire_type attribute in "server caps" operation · 264e6351
      Chuck Lever 提交于
      The fh_expire_type file attribute is a filesystem wide attribute that
      consists of flags that indicate what characteristics file handles
      on this FSID have.
      
      Our client doesn't support volatile file handles.  It should find
      out early (say, at mount time) whether the server is going to play
      shenanighans with file handles during a migration.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      264e6351
    • C
      NFS: Introduce NFS_ATTR_FATTR_V4_LOCATIONS · 81934ddb
      Chuck Lever 提交于
      The Linux NFS client must distinguish between referral events (which
      it currently supports) and migration events (which it does not yet
      support).
      
      In both types of events, an fs_locations array is returned.  But upper
      layers, not the XDR layer, should make the distinction between a
      referral and a migration.  There really isn't a way for an XDR decoder
      function to distinguish the two, in general.
      
      Slightly adjust the FATTR flags returned by decode_fs_locations()
      to set NFS_ATTR_FATTR_V4_LOCATIONS only if a non-empty locations
      array was returned from the server.  Then have logic in nfs4proc.c
      distinguish whether the locations array is for a referral or
      something else.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      81934ddb
    • C
      NFS: Simplify arguments of encode_renew() · bb4dae5e
      Chuck Lever 提交于
      Clean up: pass just the clientid4 to encode_renew().  This enables it
      to be used by callers who might not have an full nfs_client.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bb4dae5e
    • C
      NFS: Clean up debugging in decode_pathname() · 02a2976c
      Chuck Lever 提交于
      I noticed recently that decode_attr_fs_locations() is not generating
      very pretty debugging output.  The pathname components each appear on
      a separate line of output, though that does not appear to be the
      intended display behavior.  The preferred way to generate continued
      lines of output on the console is to use pr_cont().
      
      Note that incoming pathname4 components contain a string that is not
      necessarily NUL-terminated.  I did actually see some trailing garbage
      on the console.  In addition to correcting the line continuation
      problem, add a string precision format specifier to ensure that each
      component string is displayed properly, and that vsnprintf() does
      not Oops.
      
      Someone pointed out that allowing incoming network data to possibly
      generate a console line of unbounded length may not be such a good
      idea.  Since this output will rarely be enabled, and there is a hard
      upper bound (NFS4_PATHNAME_MAXCOMPONENTS) in our implementation, this
      is probably not a major concern.
      
      It might be useful to additionally sanity-check the length of each
      incoming component, however.  RFC 3530bis15 does not suggest a maximum
      number of UTF-8 characters per component for either the pathname4 or
      component4 types.  However, we could invent one that is appropriate
      for our implementation.
      
      Another possibility is to scrap all of this and print these pathnames
      in upper layers after a reasonable amount of sanity checking in the
      XDR layer.  This would give us an opportunity to allocate a full
      buffer so that the whole pathname would be output via a single
      dprintk.
      
      Introduced by commit 7aaa0b3b: "NFSv4: convert fs-locations-components
      to conform to RFC3530," (June 9, 2006).
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      02a2976c
  9. 02 3月, 2012 2 次提交
  10. 07 2月, 2012 3 次提交
  11. 04 2月, 2012 1 次提交
    • T
      NFSv4: Fix an Oops in the NFSv4 getacl code · 331818f1
      Trond Myklebust 提交于
      Commit bf118a34 (NFSv4: include bitmap
      in nfsv4 get acl data) introduces the 'acl_scratch' page for the case
      where we may need to decode multi-page data. However it fails to take
      into account the fact that the variable may be NULL (for the case where
      we're not doing multi-page decode), and it also attaches it to the
      encoding xdr_stream rather than the decoding one.
      
      The immediate result is an Oops in nfs4_xdr_enc_getacl due to the
      call to page_address() with a NULL page pointer.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      Cc: stable@vger.kernel.org
      331818f1
  12. 01 2月, 2012 1 次提交