Re: [PATCH 10/10 v7] nfsd: Allows user un-mounting filesystem where nfsd exports base on

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

On Thu, Jul 16, 2015 at 09:40:46AM +1000, NeilBrown wrote:
> On Wed, 15 Jul 2015 17:07:56 -0400 "J. Bruce Fields"
> <bfields@fieldses.org> wrote:
> 
> > > Wow.... this is turning out to be a lot more complex that I imagined at
> > > first (isn't that always the way!).
> > > 
> > > There is a lot of good stuff here, but I think we can probably make it
> > > simpler and so even better.
> > 
> > I'm still not convinced that the expkey

(Sorry, I meant an entry in the export cache, not the expkey cache.)

> should have a dentry reference
> > in the key in the first place.  Fixing that would fix the immediate
> > problem.
> 
> ???  If we removed the dentry, how would you export a subdirectory of a
> filesystem?

I've been wondering if the export cache should really be keyed on the
string representation of the path instead of the struct path.  That's
what the userspace interface uses.

There's a related bug: if there are mountpoints at both /a and /a/b,
then thanks to the lookup-underneath-mountpoint behavior of the server,
an NFSv3 client looking that up will end up going underneath the first
mountpoint and doing an export cache lookup for

	(vfsmnt, dentry) == (/, /a/b)

When the server gets a response that starts with "/a/b", it interprets
that as applying to the path (/a, /a/b), so doesn't recognize it as
resolving the query about (/, /a/b).

Well, at least I assume that's why I see "ls" hang if I run "ls
/mnt/a/b" on the client.  And there may be some better fix, but I always
figured the root (hah) problem here was due to indexing the cache on
struct path while the upcall interface uses the full path string.

--b.