Re: 2.6.38-rc2... NFS sillyrename is broken...

["J. R. Okajima" <hooanon05@yahoo.co.jp>]

(CC-ed Nick Piggin)

Trond Myklebust:
> Something in the recent VFS churn appears to have broken NFS
> sillyrename.
>
> Currently, when I try to unlink() a file that is being held open by
> another process, I do indeed see that file getting renamed to
> a .nfsxxxxxxx file, but when the file is closed, the .nfsxxxxx file
> sticks around until I unlink() it again.
>
> I'll have a look tomorrow at what is going wrong, but I figured I'd ask
> on the list in case someone has a suspect...

I noticed this issue yesterday and found the change for removing
dcache_lock is suspicious.
By the commit 949854d
	2011-01-07 fs: Use rename lock and RCU for multi-step operations
dentry->d_parent = NULL;
is added into the beginning of VFS d_kill().

Later d_kill() calls dentry_iput(), d_op->d_iput() which is
nfs_dentry_iput() in NFS.
Then nfs_dentry_iput() calls nfs_complete_unlink(), nfs_call_unlink().
Here nfs_call_unlink() calls dget_parent() and when the result is NULL,
it skips the actual unlink. Finally the "silly-renamed" dentry
remains.

Can we stop "dentry->d_parent = NULL"
when (d->flags & DCACHE_NFSFS_RENAMED) is true?


J. R. Okajima