More fun with unmounting ESTALE directories.

Commit Message

Jeff Layton Feb. 18, 2013, 7:46 p.m. UTC

On Mon, 18 Feb 2013 18:46:09 +0000
Al Viro <[e-mail]> wrote:

> On Mon, Feb 18, 2013 at 01:25:09PM +1100, NeilBrown wrote:
> 
> > I would be really nice if sys_unmount used a LOOKUP_MOUNTPOINT flag that
> > works a bit like LOOKUP_PARENT and LOOKUP_NOFOLLOW in that it skips the very
> > last step and returns the mounted-on directory, not the mountpoint that is
> > mounted there - or at least makes sure not revalidate happens on that final
> > mounted directory.
> 
> I don't think LOOKUP_MOUNTPOINT is a good idea.  For one thing, we have
> fairly few places that might want it, all of them in core VFS.  Might as
> well provide a separate function for them, a-la path_lookupat() vs.
> path_openat().
> 
> For another, we need to decide what to do with a really nasty corner case:
> 	a/b is a mountpoint, with c/d bound on it.
> 	c/d is a symlink to c/e
> 	c/e is a mountpoint
> What should umount("a/b", 0) do?  There are two possibilities - removing
> vfsmount on top of a/b or one on top of c/e...
> 
> We have the latter semantics; _that_ is what this GETATTR is about.  It's
> a fairly obscure corner case - the question is not even whether to follow
> symlinks, it's whether to follow _mounts_ on the last component.  Hell
> knows; I'm seriously tempted to change it "don't follow mounts" and see if
> anyone complains.  The only case when behaviour would change would be
> a symlink mounted somewhere (note that this is _not_ something that can easily
> happen; e.g. mount --bind does follow symlinks) and umount(2) given the
> path resolving to the mountpoint of that symlink.
>  
> > I think FS_REVAL_DOT is needed so that if you call stat("."), it will update
> > attributes from the server if the cache is old.  However it seems to do a
> > whole lot more than that, including "lookup" calls which it I'm sure is wrong.
> 
> Far from only that.  FS_REVAL_DOT is a misnomer - it's not just ".".  Take
> a look at the places where LOOKUP_JUMPED is set; _that_ is what drives the
> damn thing.  Essentially, LOOKUP_JUMPED is "we hadn't arrived here by
> lookup in parent"; "." (or "/") obviously qualify, but so does following
> a procfs-style symlink, or .., for that matter.  "foo/.", OTOH, does *not*.
> 
> It matters only in the end of the pathname, of course.  So we don't need to do
> revalidate every time we step on e.g. .. or cross a mountpoint (let alone
> when we step on .), as long as we make sure that revalidate isn't missing in
> the end of path.

Ok, that helps. In that case, this patch might be a reasonable
forward-port of the one Neil sent earlier today. Note that this doesn't
really do anything for the umount problem, but it does seem to fix the
testcase for the problem I've been looking at.

Thoughts?

---------------[snip]--------------

nfs: handle d_revalidate of 'dot' correctly

When d_revalidate is called on a dentry because FS_REVAL_DOT is set it
isn't really appropriate to revalidate the name.

If the path was simply ".", then the current-working-directory could
have been renamed on the server and should still be accessible as "."
even if it has a new name.

If the path was "/some/long/path/.", then the final component ("path" in
this case) has already been revalidated and there is no particular need
to do it again.

If LOOKUP_JUMPED is set in the flags, then that indicates that we
reached this dentry by some means other than a lookup in a parent
directory. In that case, verifying the dentry by name is pretty
meaningless. We do however want to know whether the inode is still good.

Based-on-Patch-by: NeilBrown <[e-mail]>
Signed-off-by: Jeff Layton <[e-mail]>
---
 fs/nfs/dir.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Al Viro Feb. 18, 2013, 8:15 p.m. UTC | #1

On Mon, Feb 18, 2013 at 02:46:55PM -0500, Jeff Layton wrote:

> Ok, that helps. In that case, this patch might be a reasonable
> forward-port of the one Neil sent earlier today. Note that this doesn't
> really do anything for the umount problem, but it does seem to fix the
> testcase for the problem I've been looking at.
> 
> Thoughts?

If we really go for "in this case revalidate should be weaker", we might
as well introduce a separate method for it.

As it is, we have several callers of ->d_revalidate(); this one (in
complete_walk(), only for FS_REVAL_DOT filesystems) and ones in
lookup_dcache() and lookup_fast() (in both cases we have and want the
name to match).  There are only two fs with FS_REVAL_DOT present - nfs
and 9p.  *IF* we want to make ->d_revalidate() on NFS behave differently
in complete_walk() case, it would argue for just splitting the method
in two, replacing FS_REVAL_DOT with "dentry has this method" and probably
taking a good look at what 9p needs in the same case.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Feb. 18, 2013, 11:14 p.m. UTC | #2

On Mon, 18 Feb 2013 20:15:02 +0000 Al Viro <[e-mail]> wrote:

> On Mon, Feb 18, 2013 at 02:46:55PM -0500, Jeff Layton wrote:
> 
> > Ok, that helps. In that case, this patch might be a reasonable
> > forward-port of the one Neil sent earlier today. Note that this doesn't
> > really do anything for the umount problem, but it does seem to fix the
> > testcase for the problem I've been looking at.
> > 
> > Thoughts?
> 
> If we really go for "in this case revalidate should be weaker", we might
> as well introduce a separate method for it.
> 
> As it is, we have several callers of ->d_revalidate(); this one (in
> complete_walk(), only for FS_REVAL_DOT filesystems) and ones in
> lookup_dcache() and lookup_fast() (in both cases we have and want the
> name to match).  There are only two fs with FS_REVAL_DOT present - nfs
> and 9p.  *IF* we want to make ->d_revalidate() on NFS behave differently
> in complete_walk() case, it would argue for just splitting the method
> in two, replacing FS_REVAL_DOT with "dentry has this method" and probably
> taking a good look at what 9p needs in the same case.

Sounds good to me.

Reminds me that we used to have an i_op->revalidate() method for revalidating
just the inode (not the dentry).  It called nfs_revalidate_inode() for NFS.

We lost it over a decade ago:

commit cc41b90f8a9ad3cd85a39dd4fcc71f965a675b0e
Author: Alexander Viro <[e-mail]>
Date:   Tue May 21 21:12:46 2002 -0700

    [PATCH] kill ->i_op->revalidate()
    
    kill ->i_op->revalidate()



:-)

(this doesn't help my umount problem though)

NeilBrown

Jeff Layton Feb. 19, 2013, 12:33 p.m. UTC | #3

On Tue, 19 Feb 2013 10:14:50 +1100
NeilBrown <[e-mail]> wrote:

> On Mon, 18 Feb 2013 20:15:02 +0000 Al Viro <[e-mail]> wrote:
> 
> > On Mon, Feb 18, 2013 at 02:46:55PM -0500, Jeff Layton wrote:
> > 
> > > Ok, that helps. In that case, this patch might be a reasonable
> > > forward-port of the one Neil sent earlier today. Note that this doesn't
> > > really do anything for the umount problem, but it does seem to fix the
> > > testcase for the problem I've been looking at.
> > > 
> > > Thoughts?
> > 
> > If we really go for "in this case revalidate should be weaker", we might
> > as well introduce a separate method for it.
> > 
> > As it is, we have several callers of ->d_revalidate(); this one (in
> > complete_walk(), only for FS_REVAL_DOT filesystems) and ones in
> > lookup_dcache() and lookup_fast() (in both cases we have and want the
> > name to match).  There are only two fs with FS_REVAL_DOT present - nfs
> > and 9p.  *IF* we want to make ->d_revalidate() on NFS behave differently
> > in complete_walk() case, it would argue for just splitting the method
> > in two, replacing FS_REVAL_DOT with "dentry has this method" and probably
> > taking a good look at what 9p needs in the same case.
> 
> Sounds good to me.
> 
> Reminds me that we used to have an i_op->revalidate() method for revalidating
> just the inode (not the dentry).  It called nfs_revalidate_inode() for NFS.
> 
> We lost it over a decade ago:
> 
> commit cc41b90f8a9ad3cd85a39dd4fcc71f965a675b0e
> Author: Alexander Viro <[e-mail]>
> Date:   Tue May 21 21:12:46 2002 -0700
> 
>     [PATCH] kill ->i_op->revalidate()
>     
>     kill ->i_op->revalidate()
> 
> 
> 
> :-)
> 
> (this doesn't help my umount problem though)
> 

That would work for NFS, but unfortunately I think 9p needs a dentry
operation here if we're not going to break it. Anyone want to suggest a
new name for it? I'm using d_reval_dot for now, but a better name would
be welcome...

Patch

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index a8bd28c..f159c3c 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1076,6 +1076,19 @@  static int nfs_lookup_revalidate(struct dentry *dentry, unsigned int flags)
 	if (NFS_STALE(inode))
 		goto out_bad;
 
+	/*
+	 * If we didn't reach this dentry as the result of a lookup in the
+	 * parent dir, then LOOKUP_JUMPED will be set. In that case, however
+	 * the name not really relevant, so just revalidate the inode
+	 */
+	if (flags & LOOKUP_JUMPED) {
+		error = nfs_revalidate_inode(NFS_SERVER(inode), inode);
+		if (error)
+			goto out_bad;
+		else
+			goto out_valid;
+	}
+
 	error = -ENOMEM;
 	fhandle = nfs_alloc_fhandle();
 	fattr = nfs_alloc_fattr();