Re: incorrect EXDEV error occasionally returned for rename over NFS

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Nov 23, 2010 at 02:55:24PM -0600, Joe Habermann wrote:
> Sure, I'll take another look.  I definitely would prefer a more
> elegant solution.
> 
> With regard to the strcmp on ex_client->name(), I'm not sure that's 100% tight.
> Suppose we have an export such as:
>     *(rw,sync,no_subtree_check)
> And during the race window, that export is replaced with:
>     foo(rw,sync,no_subtree_check)
> And it's "foo" that's performing the rename.
> In this case, the export pointers will (generally) be different, as
> will the auth_domain pointers, as will the string pointed to by
> ex_client->name ("*" vs. "foo"), incorrectly leading to a failing
> check.

You're devious!  We need you reading more of the NFS code....

But I think we're both being stupid here: both exports are looked up
using the same auth_domain (rq_client), and it's really the filesystems
(or filesystem subtrees) that we want to compare anyway.

So just ditch the ex_client comparison and compare the two
(vfsmount,dentry) pairs.

(There may still be an odd race or two; e.g. if someone does

	mount --bind /export/path /export/path
	exportfs -f

between the two export lookups, could we end up with two different
vfsmounts that really could be treated as the same?  But I don't think
we need to support that.

Other alternatives would be to compare something like the fs-identifying
part of the filehandle, or the path. (Probably svc_export_match() should
be strcmp()'ing paths anyway--paths are what userspace deals in anyway,
so if we're ever in a situation where it makes a difference, and there
are two (mnt,dentry) pairs that alias to the same path, then we end up
with a cache request that userspace can never respond to.))

--b.