To: viro@parcelfarce.linux.theplanet.co.uk
cc: David Howells <dhowells@cambridge.redhat.com>,
       Linus Torvalds <torvalds@transmeta.com>,
       Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] VFS autmounter support 
In-Reply-To: Message from viro@parcelfarce.linux.theplanet.co.uk 
   of "Wed, 18 Jun 2003 09:36:10 BST." <20030618083610.GB6754@parcelfarce.linux.theplanet.co.uk> 
User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4
 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 18 Jun 2003 12:01:07 +0100
Message-ID: <19254.1055934067@warthog.warthog>
From: David Howells <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3277
Lines: 77


> > > We need a light-weight automount.  No arguments here.  But it should
> > > be per-namespace - i.e. "I want to have <foo> mounted on /usr/barf on
> > > demand and I have no intention to screw somebody else - somebody who
> > > might have the same directory seen as /usr/local/debian/barf and want
> > > <blah> mounted on demand there".
> > 
> > I don't have that intention of mucking someone else up either... But
> > consider: what happens when a namespace is copied? All the automounter
> > directories for autofs/amd/AFS are copied too... With the way I've come up
> > with, this is irrelevant; the in-VFS automount will still work exactly the
> > way it did until it is removed from that namespace. This is the way _I_
> > would expect things to work.
> 
> With your patch automount will happen on every reference to dentry.
> Regardless of the namespace we are in.  

Yes, that is, I think, the correct thing to do... but see also below.

> > I don't see that your argument is a problem... anyone who wants something
> > different in their namespace is going to have to change things anyway.
> 
> And how would they do it?  You get mount triggered by stepping on dentry.
> Period.

I think that's the correct behaviour for an automounter, except for stat(),
which I'd prefer _not_ to cause this (so you can "browse").

> Your kern_automount() will then create a new vfsmount and slap it on the
> tree.  Again, regardless of the namespace we are in / vfsmount we are
> looking at / etc.

Looking at my code, I should probably use the semaphore from the namespace
pointed to by the vfsmount I'm going to be mounting on, just in case we've
managed to cross into someone else's namespace:

	int kern_automount(struct vfsmount *on_mnt, struct dentry *on_dentry)
	{
+		struct namespace *namespace = on_mnt->mnt_namespace;
		struct nameidata nd;
	...
-		down_write(&current->namespace->sem);
+		down_write(&namespace->sem);
	...
-		up_write(&current->namespace->sem);
+		up_write(&namespace->sem);
	...
	}


> I have two namespaces.  One of them has filesystem A mounted on /usr/include.
> Another - on /usr/local/include.  The first one wants /usr/include/foo1 trigger
> mounting B and /usr/include/foo2 trigger mounting C.  The second one wants
> /usr/local/include/foo1 trigger mounting D and /usr/local/include/foo2 not
> trigger anything.
> 
> Namespaces are completely unrelated - I have them set for two different
> users that happen to need some common files, but otherwise have very
> different environments.

Not exactly unrelated. If namespace A derives from namespace B during clone(),
then I would consider B should behave exactly as A until modified - including
automount facilities.

> Could you describe what that "having to change things" would involve?

Well, if you, say, cloned a shell with its own namespace with the intent of 
rearranging its namespace for that user, then I think it would be fair to say
that you'd have to "change things" at some point (ie: use (u)mount to
rearrange the topology).

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/