Re: [patch/rfc] allow exported (and *not* exported) filesystems to be unmounted.

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

On Thu, Jun 06, 2013 at 10:05:12AM +1000, NeilBrown wrote:
> On Wed, 5 Jun 2013 09:36:58 -0400 "J. Bruce Fields" <bfields@fieldses.org>
> wrote:
> 
> > On Wed, Jun 05, 2013 at 04:19:34PM +1000, NeilBrown wrote:
> > > On Wed, 5 Jun 2013 04:41:15 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > > 
> > > > On Wed, Jun 05, 2013 at 01:05:41PM +1000, NeilBrown wrote:
> > > > > 
> > > > > Hi Bruce,
> > > > >  this is a little issue that seems to keep coming up so I thought it might be
> > > > >  time to fix it.
> > > > > 
> > > > >  As you know, a filesystem that is exported cannot be unmounted as the export
> > > > >  cache holds a reference to it.  Though if it hasn't been accessed for a
> > > > >  while then it can.
> > > > > 
> > > > >  As I hadn't realised before sometimes *non* exported filesystems can be
> > > > >  pinned to.  A negative entry in the cache can pin a filesystem just as
> > > > >  easily as a positive entry.
> > > > >  An amusing, if somewhat contrived, example is that if you export '/' with
> > > > >  crossmnt and:
> > > > > 
> > > > >     mount localhost:/ /mnt
> > > > >     ls -l /
> > > > >     umount /mnt
> > > > > 
> > > > >  the umount might fail.  This is because the "ls -l" tried to export every
> > > > >  filesystem found mounted in '/'.  The export of "/mnt" failed of course
> > > > >  because you cannot re-export an NFS filesystem.  But it is still in the
> > > > >  cache.
> > > > >  An 'exportfs -f' fixes this, but shouldn't be necessary.
> > 
> > Yeah, ugh.  As a less contrived example, can the default v4 root export
> > lead to arbitrary filesystems being pinned just because a client tried
> > to mount the wrong path?
> 
> I think it can only pin filesystems that are exported, either explicitly or
> via a parent being exported with 'crossmnt'.

But see utils/mountd/v4root.c, and:

	[root@server ~]# exportfs -v
	/export <world>(rw,...)
	[root@server ~]# mount /mnt

		[root@pip4 ~]# mount pip4:/ /mnt/
		[root@pip4 ~]# ls -l /mnt/
		total 4
		drwxrwxrwt 3 root root 4096 Jun  7 10:34 export
		[root@pip4 ~]# 

	[root@server ~]# umount /mnt/
	umount: /mnt: target is busy.
	...
	[root@server ~]# grep /mnt /proc/net/rpc/nfsd.export/content 
	# /mnt	*()

> > Could the export cache be indexed on a path string instead of a struct
> > path?
> 
> Yes.  It would mean lots of extra pathname lookups and possibly lots of
> "d_path()" calls.

Right.  Ugh.  Still, struct path seems wrong as it's not something gssd
knows about, and there's not really a 1-1 mapping between the two (see
e.g. the recent complaint about the case where the struct path
represents a lazy-unmounted export
http://mid.gmane.org/<20130625191008.GA20277@us.ibm.com> ).

--b.