1. 04 8月, 2010 4 次提交
  2. 15 5月, 2010 3 次提交
  3. 23 4月, 2010 1 次提交
  4. 03 12月, 2009 1 次提交
    • T
      RPC: Fix two potential races in put_rpccred · f0380f3d
      Trond Myklebust 提交于
      It is possible for rpcauth_destroy_credcache() to cause the rpc credentials
      to be unhashed while put_rpccred is waiting for the rpc_credcache_lock on
      another cpu. Should this happen, then we can end up calling
      hlist_del_rcu(&cred->cr_hash) a second time in put_rpccred, thus causing
      list corruption.
      
      Should the credential actually be hashed, it is also possible for
      rpcauth_lookup_credcache to find and reference it before we get round to
      unhashing it. In this case, the call to rpcauth_unhash_cred will fail, and
      so we should just exit without destroying the cred.
      Reported-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f0380f3d
  5. 30 11月, 2009 1 次提交
  6. 16 9月, 2009 1 次提交
  7. 24 12月, 2008 2 次提交
    • P
      optimize attribute timeouts for "noac" and "actimeo=0" · 64672d55
      Peter Staubach 提交于
      Hi.
      
      I've been looking at a bugzilla which describes a problem where
      a customer was advised to use either the "noac" or "actimeo=0"
      mount options to solve a consistency problem that they were
      seeing in the file attributes.  It turned out that this solution
      did not work reliably for them because sometimes, the local
      attribute cache was believed to be valid and not timed out.
      (With an attribute cache timeout of 0, the cache should always
      appear to be timed out.)
      
      In looking at this situation, it appears to me that the problem
      is that the attribute cache timeout code has an off-by-one
      error in it.  It is assuming that the cache is valid in the
      region, [read_cache_jiffies, read_cache_jiffies + attrtimeo].  The
      cache should be considered valid only in the region,
      [read_cache_jiffies, read_cache_jiffies + attrtimeo).  With this
      change, the options, "noac" and "actimeo=0", work as originally
      expected.
      
      This problem was previously addressed by special casing the
      attrtimeo == 0 case.  However, since the problem is only an off-
      by-one error, the cleaner solution is address the off-by-one
      error and thus, not require the special case.
      
          Thanx...
      
              ps
      Signed-off-by: NPeter Staubach <staubach@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      64672d55
    • T
      SUNRPC: Remove the last remnant of the BKL... · 88a9fe8c
      Trond Myklebust 提交于
      Somehow, this escaped the previous purge. There should be no need to keep
      any extra locks in the XDR callbacks.
      
      The NFS client XDR code only writes into private objects, whereas all reads
      of shared objects are confined to fields that do not change, such as
      filehandles...
      
      Ditto for lockd, the NFSv2/v3 client mount code, and rpcbind.
      
      The nfsd XDR code may require the BKL, but since it does a synchronous RPC
      call from a thread that already holds the lock, that issue is moot.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      88a9fe8c
  8. 14 11月, 2008 3 次提交
  9. 29 10月, 2008 2 次提交
  10. 17 10月, 2008 1 次提交
  11. 20 4月, 2008 1 次提交
  12. 15 3月, 2008 6 次提交
  13. 30 1月, 2008 3 次提交
  14. 20 7月, 2007 1 次提交
  15. 18 7月, 2007 1 次提交
  16. 11 7月, 2007 9 次提交