> > I've revised my patch to make sure a process in one namespace doesn't
> > change the topology of another namespace (kern_automount() will return an
> > error in that case, as does (u)mount). As a bonus, check_mnt() has been
> > simplified to take account of the namespace pointer now in vfsmount.
>
> You _still_ don't get it. OK, the last time: kern_automount() will
> always do the same thing, no matter which namespace we are it. It
> might be OK for AFS, but it's definitely unfit for any other use.
Well, I disagree. I think it should do the same thing (but with results
limited to the namespace of whatever triggered the automount) until the
administrator discards that portion of the tree (umount -l will work
there). But I don't think I'm going to get anywhere arguing about it with you.
And, furthermore, I think autofs could be reimplemented in simpler form using
it (and still call out to userspace), but that's just my opinion.
> No amount of "use of (u)mount to rearrange topology" will help here -
> with your code you have dentry marked, and stepping on it (in any
> namespace, in any instance of that fs in a namespace) will always do
> the same thing. And that is Wrong(tm).
Again, I disagree. In my opinion an automount point should still work
correctly in a cloned namespace, until the filesystem that is "proposing" it
is unmounted.
If I mount an automount-capable fs on a directory, and then create a shell in
a derivative namespace, I would _expect_ the automounting to still _work_
until at such point I unmounted that automount-capable fs.
Besides, going back to your original argument, I think you make an invalid
assertion:
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.
They are not quite completely unrelated. The only way (or so it seems) to get
a new namespace is to derive one by way of CLONE_NS. This clones the namespace
of the parent, and so the child's namespace then should have all the features
of the parent's namespace _UNTIL_ at such time the child or one of its
descendents rearranges the topology!
If the two users need very different environments, then they'll change their
namespace to suit themselves - thus making my point.
Creating a new namespace does _not_ automatically confer a complete new
topology of an independent predetermined design, nor does it generate a
totally empty namespace.
But, barring that, you are correct... changes to one namespace do not impinge
on any other (/proc not withstanding). My patch honours this. Tripping an
automount point in one namespace does not change another namespace.
| 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.
Firstly, if one of these topologies has been derived from the other, then one
or both of them have been rearranged since the point of divergence. You have
implied that.
Secondly, if "filesystem A" provides those automount points, then it is a
different filesystem in each case, but obviously you're not thinking along
those lines.
What you appear to be thinking of is that some independent third party (autofs
daemon, administrator or whatever) has glued on arbitrary automounting
triggers (perhaps by mounting them).
I think this can make use of my suggested change... If you make a trigger fs
that has its root directory simply an automount point (though this leads me to
think that perhaps (u)mount should follow the example of stat and use
LOOKUP_NOAUTOMOUNT).
Perhaps:
[namespace X]
mount /dev/hda8 /usr/include
mount -t trap "mount-fs-B" /usr/include/foo1
mount -t trap "mount-fs-C" /usr/include/foo2
[namespace Y]
mount /dev/hda8 /usr/local/include
mount -t trap "mount-fs-D" /usr/local/include/foo1
Then have a daemon that can take a request to mount and then reply with the
mount parameters, allowing the trap fs to obtain a vfsmount via
do_kern_mount(). I would make the trap fs supply the daemon with an fd
attached to the trap rootdir to act as a token representing the request (and
controlling its lifetime).
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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:29 EST