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

From: Linus Torvalds <torvalds@transmeta.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: viro@parcelfarce.linux.theplanet.co.uk,
	Frank Cusack <fcusack@fcusack.com>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nfs_unlink() race (was: nfs_refresh_inode: inode number mismatch)
Date: Wed, 11 Jun 2003 08:08:56 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0306110804360.4413-100000@home.transmeta.com> (raw)
In-Reply-To: <1055334814.2084.12.camel@dhcp22.swansea.linux.org.uk>

On 11 Jun 2003, Alan Cox wrote:
> 
> For vfat at least its all broken. 

Looks like a different issue, not dentry aliasing per se.

> cd foo
> mv ../file .
> more file
> 
> ESTALE.

Yes, VFAT ends up encoding the parent directory in the FH, so renaming 
will invalidate the old file handle, and if you cache inodes (and thus 
filehandles) over a directory move, badness happens.

Arguably it's a NFS client problem - the path revalidate at open time 
should have caught the ESTALE and forced a new inode lookup. But I think 
you can also argue that VFAT over NFS is just non-unixy enough that it 
just isn't really "supported".

I think it's more of a "you can NFS-export strange filesystems for some
limited file sharing, but if things break, you get to keep both pieces".

		Linus