Re: [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch)

[Frank Cusack]

On Wed, Jun 11, 2003 at 03:27:54AM +0100, [e-mail] wrote:
> On Wed, Jun 11, 2003 at 03:59:10AM +0200, Trond Myklebust wrote:
> > IOW we just want to prevent VFS from unhashing the dentry in the first
> > place: dentry aliasing cannot work together with sillyrename.
> 
> Aliasing could be dealt with.  They would have the same inode, so it's
> easy to detect.

dentry only contains the inode, not the fh.  On the server, the inode
can go away and come back as a new fh, but with the same inode.  Is
that detectable (would comparison hooks have to be added?)?  Although,
I guess the inode is enough; you can do an NFS_I(inode)->fh to get
the fh, but I wouldn't guess you'd want that in the VFS.  Bah, here
I go again ... forgive me if that's nonsense.

>  The real problem is different: what happens if I take
> silly-renamed file and rename it away?  You suddenly get ->dir and ->dentry
> if your nfs_unlinkdata having nothing to do with each other.

You could disallow rename if DCACHE_NFSFS_RENAMED is set.  That would
be easy and makes sense as an "ok" thing to do.  I mean, if you're not
going to allow unlinking of a sillyrenamed file, you may as well disallow
rename as well.

If that's not desirable (again, seems ok to me ... speaking as just a user)
then hey, in rename you just need to check the nfs_delete_queue.

> _If_ we want to be able to work with silly-renamed dentry, we need much
> more careful async unlink.  Your current code assumes that these dentries
> won't go anywhere.   AFAICS, dcache will not get into inconsistent state,
> but it will have very little to do with state of server...

OK, where else besides rename would the dentry change?

/fc