Re: Removing shared subtrees?

From: Andy Lutomirski
Date: Mon Sep 29 2014 - 22:41:23 EST

On Mon, Sep 29, 2014 at 7:21 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Sep 29, 2014 at 06:24:05PM -0700, Andy Lutomirski wrote:
>> On Mon, Sep 29, 2014 at 6:14 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, Sep 29, 2014 at 05:36:27PM -0700, Andy Lutomirski wrote:
>> >
>> >> Ideally it would leave them around until the whole subtree had no
>> >> references, at which point /mnt and everything under it would
>> >> disappear with no side effects, because it has no references.
>> >
>> > So, assuming you've got a stuck NFS mount with a bunch of local stuff
>> > bound on top of it, in your ideal we'd have the latter all remaining
>> > mounted until the server comes back. Lovely, that...
>> No, not at all.
> Er... How so? /mnt is stuck NFS. /mnt/foo/bar and /mnt/foo/barf have
> /dev/sda1 and /dev/sda2 mounted on them. Both are currently not busy.
> /mnt is - there's that shell trying to expand *.c in /mnt/splat, sitting
> around blocked with opened directory in its descriptor table.
> Just how would your ideal prevent sda1 and sda2 staying mounted? You can't
> say umount /mnt/foo/bar; it'll get blocked trying to revalidate foo and
> waiting for server to reply. In real world you can say umount -l /mnt and
> be done with that - everything in there becomes detached, what used to be
> /mnt stays alive (but not mounted on /mnt anymore) until it ceases to be
> busy. What used to be /mnt/foo/bar and /mnt/foo/barf end up shut down
> immediately (what with not being busy). In your ideal they would stay around
> until the "whole subtree" (of what?) loses all references, i.e. until that
> shell closes opened directory.

I don't want /mnt/foo/far to stay mounted. I do, however, want their
peers, if any, to stay mounted *if /mnt is the root of a shared
recursive bind mount*.

>> Let me try this one more time:
>> I don't *care* whether MNT_DETACH unmounts submounts immediately or
>> when all the references are finally gone. I didn't read the docs or
>> the code to see which is the case *because I don't care*.
>> I think it's somewhere between ridiculous and flat-out broken that
>> MNT_DETACH of the *root* of a shared subtree *propagates* the unmount
>> of submounts to the parent of the shared subtree. This is IMO
>> completely bogus.
> Parent in which sense? Try to experiment with this: mount something on
> /tmp/foo, then mount --rbind /tmp/foo /mnt/foo, mount something on /mnt/bar
> and /tmp/bar and umount -l /mnt/foo. Then think what does and does not
> happen.
>> IOW, if I do:
>> mount --make-rshared /
>> mount --rbind / /mnt
>> umount -l /mnt/dev
>> then I fully expect /dev to be unmounted (although I think that this
>> is a misfeature).
>> But I did:
>> mount --make-rshared /
>> mount --rbind / /mnt
>> umount -l /mnt <- the ROOT of the fscking shared subtree
>> And /dev got unmounted. How does this make any sense at all?
> Sigh... umount -l /mnt *includes* unmounting /mnt/dev. Which you
> do expect to take /dev out.

I expect:

mount --rbind / /mnt
umount -l /mnt/dev

to detach /dev.

I expect:

mount --rbind / /mnt
umount -l /mnt

to have no net effect.

Another way of thinking about this would be that I would expect the
umount -l to propogate as a unit rather than propagating as a bunch of
individual unmounts. For example:

mount --rbind / /mnt
umount -l /mnt/dev

means "detach /mnt/dev from /mnt and, due to sharing, detach /dev from /"


mount --rbind / /mnt
umount -l /mnt

means "detach /mnt from /" but does not unmount / or other things in
/. IOW MNT_DETACH should only propagate detach of submounts if a
umount without MNT_DETACH would propagate.

In this case, mount --rbind / /mnt; umount /mnt would either fail with
-EBUSY or *not* propagate because it's the root of the shared subtree.

Anyway, improving the MNT_DETACH docs to recommend doing MS_PRIVATE
first if you're just trying to remove an rbind would solve most of the

In any event, I still don't understand why we have shared recursive
bind mounts in the first place. What are they used for that wouldn't
be better served by slave mounts?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at