1. 27 11月, 2012 3 次提交
  2. 05 11月, 2012 1 次提交
  3. 03 10月, 2012 2 次提交
  4. 02 10月, 2012 1 次提交
    • W
      NFSv4: Add ACCESS operation to OPEN compound · 6168f62c
      Weston Andros Adamson 提交于
      The OPEN operation has no way to differentiate an open for read and an
      open for execution - both look like read to the server. This allowed
      users to read files that didn't have READ access but did have EXEC access,
      which is obviously wrong.
      
      This patch adds an ACCESS call to the OPEN compound to handle the
      difference between OPENs for reading and execution.  Since we're going
      through the trouble of calling ACCESS, we check all possible access bits
      and cache the results hopefully avoiding an ACCESS call in the future.
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6168f62c
  5. 29 9月, 2012 1 次提交
  6. 27 9月, 2012 1 次提交
  7. 07 9月, 2012 1 次提交
  8. 06 9月, 2012 1 次提交
  9. 17 8月, 2012 2 次提交
  10. 31 7月, 2012 2 次提交
  11. 29 6月, 2012 4 次提交
  12. 05 6月, 2012 2 次提交
    • T
      NFSv4: Fix up decode_attr_mdsthreshold · 029c5347
      Trond Myklebust 提交于
      Fix an incorrect use of 'likely()'. The FATTR4_WORD2_MDSTHRESHOLD
      bit is only expected in NFSv4.1 OPEN calls, and so is actually
      rather _unlikely_.
      
      decode_attr_mdsthreshold needs to clear FATTR4_WORD2_MDSTHRESHOLD
      from the attribute bitmap after it has decoded the data.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      029c5347
    • T
      NFSv4: Fix an Oops in the open recovery code · 1549210f
      Trond Myklebust 提交于
      The open recovery code does not need to request a new value for the
      mdsthreshold, and so does not allocate a struct nfs4_threshold.
      The problem is that encode_getfattr_open() will still request an
      mdsthreshold, and so we end up Oopsing in decode_attr_mdsthreshold.
      
      This patch fixes encode_getfattr_open so that it doesn't request an
      mdsthreshold when the caller isn't asking for one. It also fixes
      decode_attr_mdsthreshold so that it errors if the server returns
      an mdsthreshold that we didn't ask for (instead of Oopsing).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Andy Adamson <andros@netapp.com>
      1549210f
  13. 27 5月, 2012 2 次提交
  14. 26 5月, 2012 1 次提交
  15. 25 5月, 2012 2 次提交
  16. 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
  17. 02 5月, 2012 6 次提交
  18. 28 4月, 2012 5 次提交
  19. 21 4月, 2012 1 次提交