NFS sillyrenamed files are not being deleted after close

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Amschuma (Talk | contribs)
(Created page with "== About == * Kernel version: 2.6.38-rc7 * [https://bugzilla.kernel.org/show_bug.cgi?id=30752 Bug 30752] * Reported by: Jeff Layton (March 8, 2011) * Fixed by: Trond Myklebust (M...")
Newer edit →

Revision as of 18:53, 28 July 2011

About

  • Kernel version: 2.6.38-rc7
  • Bug 30752
  • Reported by: Jeff Layton (March 8, 2011)
  • Fixed by: Trond Myklebust (March 25, 2011)

Symptoms

  • The new vfs locking scheme introduced in 2.6.38 breaks NFS sillyrename because the latter relies on being able to determine the parent directory of the dentry in the ->iput() callback in order to send the appropriate unlink rpc call.
  • Looking at the code that cares about races with dput(), there doesn't seem to be anything that specifically uses d_parent as a test for whether or not there is a race:
    • __d_lookup_rcu(), __d_lookup() all test for d_hashed() after d_parent
    • shrink_dcache_for_umount() is safe since nothing else can rearrange the dentries in that super block.
    • have_submount(), select_parent() and d_genocide() can test for a deletion if we set the CACHE_DISCONNECTED flag when the dentry is removed from the parent's d_subdirs list.


Resolution

commit c83ce989cb5ff86575821992ea82c4df5c388ebc
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Tue Mar 15 13:36:43 2011 -0400

    VFS: Fix the nfs sillyrename regression in kernel 2.6.38

    VFS: Fix the nfs sillyrename regression in kernel 2.6.38
    
    The new vfs locking scheme introduced in 2.6.38 breaks NFS sillyrename
    because the latter relies on being able to determine the parent
    directory of the dentry in the ->iput() callback in order to send the
    appropriate unlink rpc call.
    
    Looking at the code that cares about races with dput(), there doesn't
    seem to be anything that specifically uses d_parent as a test for
    whether or not there is a race:
      - __d_lookup_rcu(), __d_lookup() all test for d_hashed() after d_parent
      - shrink_dcache_for_umount() is safe since nothing else can rearrange
        the dentries in that super block.
      - have_submount(), select_parent() and d_genocide() can test for a
        deletion if we set the DCACHE_DISCONNECTED flag when the dentry
        is removed from the parent's d_subdirs list.
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Cc: stable@kernel.org (2.6.38, needs commit c826cb7dfce8 "dcache.c:
        create helper function for duplicated functionality" )
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
<pre>
Personal tools