lkml.org 
[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] VFS autmounter support v2
    Date
    From

    > > 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/

    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:0.048 / U:0.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site