1. 17 7月, 2012 1 次提交
    • C
      NFS: Fix up TEST_STATEID and FREE_STATEID return code handling · 377e507d
      Chuck Lever 提交于
      The TEST_STATEID and FREE_STATEID operations can return
      -NFS4ERR_BAD_STATEID, -NFS4ERR_OLD_STATEID, or -NFS4ERR_DEADSESSION.
      
      nfs41_{test,free}_stateid() should not pass these errors to
      nfs4_handle_exception() during state recovery, since that will
      recursively kick off state recovery again, resulting in a deadlock.
      
      In particular, when the TEST_STATEID operation returns NFS4_OK,
      res.status can contain one of these errors.  _nfs41_test_stateid()
      replaces NFS4_OK with the value in res.status, which is then returned
      to callers.
      
      But res.status is not passed through nfs4_stat_to_errno(), and thus is
      a positive NFS4ERR value.  Currently callers are only interested in
      !NFS4_OK, and nfs4_handle_exception() ignores positive values.
      
      Thus the res.status values are currently ignored by
      nfs4_handle_exception() and won't cause the deadlock above.  Thanks to
      this missing negative, it is only when these operations fail (which
      is very rare) that a deadlock can occur.
      
      Bryan agrees the original intent was to return res.status as a
      negative NFS4ERR value to callers of nfs41_test_stateid().
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      377e507d
  2. 14 7月, 2012 1 次提交
    • M
      nfs: clean up ->create in nfs_rpc_ops · 8867fe58
      Miklos Szeredi 提交于
      Don't pass nfs_open_context() to ->create().  Only the NFS4 implementation
      needed that and only because it wanted to return an open file using open
      intents.  That task has been replaced by ->atomic_open so it is not necessary
      anymore to pass the context to the create rpc operation.
      
      Despite nfs4_proc_create apparently being okay with a NULL context it Oopses
      somewhere down the call chain.  So allocate a context here.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      CC: Trond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8867fe58
  3. 29 6月, 2012 9 次提交
  4. 12 6月, 2012 1 次提交
  5. 08 6月, 2012 2 次提交
  6. 07 6月, 2012 1 次提交
  7. 05 6月, 2012 2 次提交
    • T
      NFSv4.1: Convert a trivial printk into a dprintk · 08106ac7
      Trond Myklebust 提交于
      There is no need to bug the user about the server returning an error
      on destroy_session. The error will be handled by the state manager,
      without any need for further input from anyone else.
      So convert that printk into a debugging dprintk.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      08106ac7
    • 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
  8. 29 5月, 2012 1 次提交
  9. 28 5月, 2012 2 次提交
  10. 27 5月, 2012 2 次提交
  11. 26 5月, 2012 2 次提交
  12. 25 5月, 2012 3 次提交
  13. 24 5月, 2012 2 次提交
  14. 23 5月, 2012 7 次提交
    • 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
    • C
      NFS: Force server to drop NFSv4 state · 2c820d9a
      Chuck Lever 提交于
      nfs4_reset_all_state() refreshes the boot verifier a server sees to
      trigger that server to wipe this client's state.  This function is
      invoked when an NFSv4.1 server reports that it has revoked some or
      all of a client's NFSv4 state.
      
      To facilitate server trunking discovery, we will eventually want to
      move the cl_boot_time field to a more global structure.  The Uniform
      Client String model (and specifically, server trunking detection)
      requires that all servers see the same boot verifier until the client
      actually does reboot, and not a fresh verifier every time the client
      unmounts and remounts the server.
      
      Without the cl_boot_time field, however, nfs4_reset_all_state() will
      have to find some other way to force the server to purge the client's
      NFSv4 state.
      
      Because these verifiers are opaque (ie, the server doesn't know or
      care that they happen to be timestamps), we can force the server
      to wipe NFSv4 state by updating the boot verifier as we do now, then
      immediately afterwards establish a fresh client ID using the old boot
      verifier again.
      
      Hopefully there are no extra paranoid server implementations that keep
      track of the client's boot verifiers and prevent clients from reusing
      a previous one.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2c820d9a
    • C
      NFS: Clean up return code checking in nfs4_proc_exchange_id() · 177313f1
      Chuck Lever 提交于
      Clean up: update to use matching types in "if" expressions.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      177313f1
    • C
      NFS: Use proper naming conventions for nfs_client.impl_id field · 59155546
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Additionally, for consistency, move the impl_id field into the NFSv4-
      specific part of the nfs_client, and free that memory in the logic
      that shuts down NFSv4 nfs_clients.
      
      Introduced by commit 7d2ed9ac "NFSv4: parse and display server
      implementation ids," Fri Feb 17, 2012.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      59155546
    • C
      NFS: Use proper naming conventions for NFSv4.1 server scope fields · 79d4e1f0
      Chuck Lever 提交于
      Clean up:  When naming fields and data types, follow established
      conventions to facilitate accurate grep/cscope searches.
      
      Additionally, for consistency, move the scope field into the NFSv4-
      specific part of the nfs_client, and free that memory in the logic
      that shuts down NFSv4 nfs_clients.
      
      Introduced by commit 99fe60d0 "nfs41: exchange_id operation", April
      1 2009.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      79d4e1f0
    • C
      NFS: Don't swap bytes in nfs4_construct_boot_verifier() · c3607282
      Chuck Lever 提交于
      The SETCLIENTID boot verifier is opaque to NFSv4 servers, thus there
      is no requirement for byte swapping before the client puts the
      verifier on the wire.
      
      This treatment is similar to other timestamp-based verifiers.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c3607282
  15. 20 5月, 2012 1 次提交
  16. 15 5月, 2012 2 次提交
  17. 11 5月, 2012 1 次提交
    • L
      vfs: make it possible to access the dentry hash/len as one 64-bit entry · 26fe5750
      Linus Torvalds 提交于
      This allows comparing hash and len in one operation on 64-bit
      architectures.  Right now only __d_lookup_rcu() takes advantage of this,
      since that is the case we care most about.
      
      The use of anonymous struct/unions hides the alternate 64-bit approach
      from most users, the exception being a few cases where we initialize a
      'struct qstr' with a static initializer.  This makes the problematic
      cases use a new QSTR_INIT() helper function for that (but initializing
      just the name pointer with a "{ .name = xyzzy }" initializer remains
      valid, as does just copying another qstr structure).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26fe5750