On Fri, 2013-02-22 at 18:02 +0000, Myklebust, Trond wrote: > On Tue, 2013-02-19 at 08:59 -0500, Dave Wysochanski wrote: > > Commit 73ca100 broke the code that prevents the client from deleting > > a silly renamed dentry. This affected "delete on last close" > > semantics as after that commit, nothing prevented removal of > > silly-renamed files. As a result, a process holding a file open > > could easily get an ESTALE on the file in a directory where some > > other process issued 'rm -rf some_dir_containing_the_file' twice. > > Before the commit, any attempt at unlinking silly renamed files would > > fail inside may_delete() with -EBUSY because of the > > DCACHE_NFSFS_RENAMED flag. The following testcase demonstrates > > the problem: > > tail -f /nfsmnt/dir/file & > > rm -rf /nfsmnt/dir > > rm -rf /nfsmnt/dir > > # second removal does not fail, 'tail' process receives ESTALE > > Hi Dave, > > I'm not sure I understand why we must do the dropping/moving of the > dentries inside nfs_async_rename_done. Why isn't something like the > attached patch sufficient? > As far as I can tell, it is sufficient. My solution was overly complex and your refinement is much more elegant. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
