1. 03 May, 2010 1 commit
  2. 22 Apr, 2010 7 commits
  3. 19 Apr, 2010 1 commit
  4. 17 Apr, 2010 1 commit
  5. 02 Apr, 2010 4 commits
  6. 30 Mar, 2010 1 commit
  7. 24 Mar, 2010 1 commit
  8. 22 Mar, 2010 1 commit
    • Jeff Layton's avatar
      nfsd: don't break lease while servicing a COMMIT · 91885258
      Jeff Layton authored
      This is the second attempt to fix the problem whereby a COMMIT call
      causes a lease break and triggers a possible deadlock.
      
      The problem is that nfsd attempts to break a lease on a COMMIT call.
      This triggers a delegation recall if the lease is held for a delegation.
      If the client is the one holding the delegation and it's the same one on
      which it's issuing the COMMIT, then it can't return that delegation
      until the COMMIT is complete. But, nfsd won't complete the COMMIT until
      the delegation is returned. The client and server are essentially
      deadlocked until the state is marked bad (due to the client not
      responding on the callback channel).
      
      The first patch attempted to deal with this by eliminating the open of
      the file altogether and simply had nfsd_commit pass a NULL file pointer
      to the vfs_fsync_range. That would conflict with some work in progress
      by Christoph Hellwig to clean up the fsync interface, so this patch
      takes a different approach.
      
      This declares a new NFSD_MAY_NOT_BREAK_LEASE access flag that indicates
      to nfsd_open that it should not break any leases when opening the file,
      and has nfsd_commit set that flag on the nfsd_open call.
      
      For now, this patch leaves nfsd_commit opening the file with write
      access since I'm not clear on what sort of access would be more
      appropriate.
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      91885258
  9. 16 Mar, 2010 1 commit
  10. 15 Mar, 2010 1 commit
    • NeilBrown's avatar
      sunrpc: never return expired entries in sunrpc_cache_lookup · d202cce8
      NeilBrown authored
      If sunrpc_cache_lookup finds an expired entry, remove it from
      the cache and return a freshly created non-VALID entry instead.
      This ensures that we only ever get a usable entry, or an
      entry that will become usable once an update arrives.
      i.e. we will never need to repeat the lookup.
      
      This allows us to remove the 'is_expired' test from cache_check
      (i.e. from cache_is_valid).  cache_check should never get an expired
      entry as 'lookup' will never return one.  If it does happen - due to
      inconvenient timing - then just accept it as still valid, it won't be
      very much past it's use-by date.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      d202cce8
  11. 14 Mar, 2010 2 commits
  12. 09 Mar, 2010 1 commit
  13. 08 Mar, 2010 18 commits