Re: [PATCH] nfs: Don't allow NFS silly-renamed files to be deleted, no signal

[David Wysochanski <dwysocha@redhat.com>]

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.