Return-Path: Received: from fieldses.org ([173.255.197.46]:35704 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752150AbbGPUvt (ORCPT ); Thu, 16 Jul 2015 16:51:49 -0400 Date: Thu, 16 Jul 2015 16:51:48 -0400 From: "J. Bruce Fields" To: NeilBrown Cc: Kinglong Mee , Al Viro , "linux-nfs@vger.kernel.org" , linux-fsdevel@vger.kernel.org, Trond Myklebust Subject: Re: [PATCH 10/10 v7] nfsd: Allows user un-mounting filesystem where nfsd exports base on Message-ID: <20150716205148.GC10673@fieldses.org> References: <55A11010.6050005@gmail.com> <55A111A8.2040701@gmail.com> <20150713133934.6a4ef77d@noble> <20150715210756.GE21669@fieldses.org> <20150716094046.445c038b@noble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20150716094046.445c038b@noble> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Thu, Jul 16, 2015 at 09:40:46AM +1000, NeilBrown wrote: > On Wed, 15 Jul 2015 17:07:56 -0400 "J. Bruce Fields" > 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.