Re: Rename dir on server can cause client to get ESTALE - this time with PATCH

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, Nov 30, 2011 at 09:24:18PM -0500, Trond Myklebust wrote:

> > As far as I can tell, the idea of open done in ->d_revalidate() is
> > unsalvagable.  It's simply the wrong place for that.  Note that NFS
> > is the only filesystem trying to do atomic open stuff in its ->d_revalidate()
> > and it's not succeeding.
> 
> Not doing an open there is prohibitively expensive, though: you are
> likely to see your cached inode flushed down the toilet if you just drop
> the dentry...

Wrong.  All you really need is to have that attempt to issue OPEN shifted
into ->open() itself.  The only interesting part is that we might need
to drop the original dentry and use a new one for ->f_path.dentry.

Don't drop that dentry; after the case in ->d_revalidate() that would have
attempted that OPEN you would either cross into covering vfsmount (in which
case dentry should be left alone as you are doing now) or issue ->open().
If it's really not valid (i.e. if OPEN yields a different inode), we can
deal with that in ->open() just fine.  The *only* subtle part is how to
deal with "it's a symlink, go away" from the server.  Which will require
changes in do_last().  I have that stuff; it'll need debugging serious
review once posted.  Which I'm going to do over weekend.