Removing shared subtrees?

Removing shared subtrees?

[Andy Lutomirski]

As far as I know, shared subtrees in recursive bind mounts are a
misfeature that existed for the sole purpose of allowing recursive
binds + chroot to emulate mount namespaces.  But we have mount
namespaces, so what are they for?

They're totally fsked up.  For example, don't try this on a live system:

# mount --make-rshared /
# mount --rbind / /mnt
# umount -l /mnt

It will unmount *everything*.  On Fedora, you don't even need the
--make-rshared part.  WTF?

Can we just remove the feature entirely in linux-next and see if
anyone complains?  I'm all for propagation across mount namespaces,
but I suspect that, at the very least, there is no legitimate reason
whatsoever for mounts to propagate from a recursive bind mount back to
the origin.

IOW, can we kill shared mounts and just keep private and slave mounts?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: Removing shared subtrees?

[Al Viro]

On Mon, Sep 29, 2014 at 04:45:42PM -0700, Andy Lutomirski wrote:
> As far as I know, shared subtrees in recursive bind mounts are a
> misfeature that existed for the sole purpose of allowing recursive
> binds + chroot to emulate mount namespaces.

Wrong.  Different namespaces vs. multiple mounts in the same namespace
have nothing whatsoever with shared vs. slave.  It's completely orthogonal.

>  But we have mount
> namespaces, so what are they for?

???

> They're totally fsked up.  For example, don't try this on a live system:
> 
> # mount --make-rshared /
> # mount --rbind / /mnt
> # umount -l /mnt
> 
> It will unmount *everything*.

So will umount -l /

>  On Fedora, you don't even need the
> --make-rshared part.  WTF?

"Doctor, it hurts when I do it..."

I can suggest a few more self-LARTs, if you are interested...

> Can we just remove the feature entirely in linux-next and see if
> anyone complains?  I'm all for propagation across mount namespaces,
> but I suspect that, at the very least, there is no legitimate reason
> whatsoever for mounts to propagate from a recursive bind mount back to
> the origin.
> 
> IOW, can we kill shared mounts and just keep private and slave mounts?

What for?

Re: Removing shared subtrees?

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 5:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Sep 29, 2014 at 04:45:42PM -0700, Andy Lutomirski wrote:
>> As far as I know, shared subtrees in recursive bind mounts are a
>> misfeature that existed for the sole purpose of allowing recursive
>> binds + chroot to emulate mount namespaces.
>
> Wrong.  Different namespaces vs. multiple mounts in the same namespace
> have nothing whatsoever with shared vs. slave.  It's completely orthogonal.
>
>>  But we have mount
>> namespaces, so what are they for?
>
> ???

No, really, what is this VFS feature for?  It's a complicated,
confusing chunk of code.  Why is it there?

>
>> They're totally fsked up.  For example, don't try this on a live system:
>>
>> # mount --make-rshared /
>> # mount --rbind / /mnt
>> # umount -l /mnt
>>
>> It will unmount *everything*.
>
> So will umount -l /
>
>>  On Fedora, you don't even need the
>> --make-rshared part.  WTF?
>
> "Doctor, it hurts when I do it..."

I understand that:

# mount --make-rshared /
# mount --rbind / /mnt
# umount - /mnt/dev

should unmount /dev.  That's the whole point.  But why does unmounting
*/mnt* propagate like that?  It doesn't unmount /.  To me, this makes
about as much sense as having 'umount -l /mnt/dev' unmount /dev/pts
but *not* /dev would make.

>
> I can suggest a few more self-LARTs, if you are interested...
>
>> Can we just remove the feature entirely in linux-next and see if
>> anyone complains?  I'm all for propagation across mount namespaces,
>> but I suspect that, at the very least, there is no legitimate reason
>> whatsoever for mounts to propagate from a recursive bind mount back to
>> the origin.
>>
>> IOW, can we kill shared mounts and just keep private and slave mounts?
>
> What for?

Simplicity and comprehensibility.

--Andy

Re: Removing shared subtrees?

[Al Viro]

On Mon, Sep 29, 2014 at 05:14:55PM -0700, Andy Lutomirski wrote:
> I understand that:
> 
> # mount --make-rshared /
> # mount --rbind / /mnt
> # umount - /mnt/dev
> 
> should unmount /dev.  That's the whole point.  But why does unmounting
> */mnt* propagate like that?  It doesn't unmount /.  To me, this makes
> about as much sense as having 'umount -l /mnt/dev' unmount /dev/pts
> but *not* /dev would make.

Aha.  And what, pray tell, does umount -l /mnt do to mounts deeper in
the tree?  Forget about shared, etc. - what, in your opinion, does umount -l
mean wrt the stuff mounted on /mnt?  /mnt/dev, for example...

> > What for?
> 
> Simplicity and comprehensibility.

Such an elegant way to say "I can't be arsed to read"...  For what it's
worth: MNT_DETACH is *not* "detach the subtree as whole, busy or not".
It's "unmount all mounts within the subtree, busy or not".  At which point
the self-LART you keep describing becomes quite easy to comprehend, doesn't
it?

Re: Removing shared subtrees?

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 5:29 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Sep 29, 2014 at 05:14:55PM -0700, Andy Lutomirski wrote:
>> I understand that:
>>
>> # mount --make-rshared /
>> # mount --rbind / /mnt
>> # umount - /mnt/dev
>>
>> should unmount /dev.  That's the whole point.  But why does unmounting
>> */mnt* propagate like that?  It doesn't unmount /.  To me, this makes
>> about as much sense as having 'umount -l /mnt/dev' unmount /dev/pts
>> but *not* /dev would make.
>
> Aha.  And what, pray tell, does umount -l /mnt do to mounts deeper in
> the tree?  Forget about shared, etc. - what, in your opinion, does umount -l
> mean wrt the stuff mounted on /mnt?  /mnt/dev, for example...

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.

I suspect it detaches them immediately, especially after reading the
rest of your email.

>
>> > What for?
>>
>> Simplicity and comprehensibility.
>
> Such an elegant way to say "I can't be arsed to read"...  For what it's
> worth: MNT_DETACH is *not* "detach the subtree as whole, busy or not".
> It's "unmount all mounts within the subtree, busy or not".  At which point
> the self-LART you keep describing becomes quite easy to comprehend, doesn't
> it?

Again, *I have no problem with the current semantics of umount -l*,
except insofar as they interact really nastily with shared subtrees.
I have a problem with bidirectional shared subtrees *in general*.

--Andy

Re: Removing shared subtrees?

[Al Viro]

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

> I suspect it detaches them immediately, especially after reading the
> rest of your email.

IOW, you *still* have not bothered to say man umount and read the manpage?

Quote:
       -l     Lazy  unmount.  Detach  the filesystem from the filesystem
              hierarchy now, and cleanup all references to the filesystem as
              soon as it is not busy anymore.  (Requires kernel 2.4.11 or
              later.)

> > Such an elegant way to say "I can't be arsed to read"...  For what it's
> > worth: MNT_DETACH is *not* "detach the subtree as whole, busy or not".
> > It's "unmount all mounts within the subtree, busy or not".  At which point
> > the self-LART you keep describing becomes quite easy to comprehend, doesn't
> > it?
> 
> Again, *I have no problem with the current semantics of umount -l*,
> except insofar as they interact really nastily with shared subtrees.
> I have a problem with bidirectional shared subtrees *in general*.

Pardon me, but it really looks like your problem is with reading.  In general
or not, but you are essentially complaining that your *guess* concerning the
semantics of this and that doesn't match the reality all that well, and its
combination with observed bits and pieces is really confusing.

BTW, I certainly agree that documentation of the mount-related utils and
syscalls could've been better.  But you clearly have never bothered to
read the existing one.  I'm sorry, but "I've used this utility with that
flag as root without ever checking what the manpage says about that
flag; results are painful and incomprehensible; whaddya mean, read the
fine manpage?" buys you very little sympathy.

Re: Removing shared subtrees?

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 6:14 PM, Al Viro <viro@zeniv.linux.org.uk> 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.

>
>> I suspect it detaches them immediately, especially after reading the
>> rest of your email.
>
> IOW, you *still* have not bothered to say man umount and read the manpage?
>
> Quote:
>        -l     Lazy  unmount.  Detach  the filesystem from the filesystem
>               hierarchy now, and cleanup all references to the filesystem as
>               soon as it is not busy anymore.  (Requires kernel 2.4.11 or
>               later.)
>
>> > Such an elegant way to say "I can't be arsed to read"...  For what it's
>> > worth: MNT_DETACH is *not* "detach the subtree as whole, busy or not".
>> > It's "unmount all mounts within the subtree, busy or not".  At which point
>> > the self-LART you keep describing becomes quite easy to comprehend, doesn't
>> > it?

The manpage you quoted doesn't seem to agree with what you just said.
Or at least, it contains nothing that, to me, would indicate that.
But...

>>
>> Again, *I have no problem with the current semantics of umount -l*,
>> except insofar as they interact really nastily with shared subtrees.
>> I have a problem with bidirectional shared subtrees *in general*.
>
> Pardon me, but it really looks like your problem is with reading.  In general
> or not, but you are essentially complaining that your *guess* concerning the
> semantics of this and that doesn't match the reality all that well, and its
> combination with observed bits and pieces is really confusing.
>
> BTW, I certainly agree that documentation of the mount-related utils and
> syscalls could've been better.  But you clearly have never bothered to
> read the existing one.  I'm sorry, but "I've used this utility with that
> flag as root without ever checking what the manpage says about that
> flag; results are painful and incomprehensible; whaddya mean, read the
> fine manpage?" buys you very little sympathy.

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.

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?

I further claim that the entire concept of shared (as opposed to
slave) subtrees is essentially worthless and should possibly be
deprecated or removed outright.

--Andy

Re: Removing shared subtrees?

[Al Viro]

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@zeniv.linux.org.uk> 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.

> 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 Y to cause Z; I don't care if X
causes Y; why does it end up causing W?!!!?"  Where W is vague as hell
and depending on what is meant either refers to Z or to something more
than that; in the letter case the answer would be "W isn't happening".

Re: Removing shared subtrees?

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 7:21 PM, Al Viro <viro@zeniv.linux.org.uk> 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@zeniv.linux.org.uk> 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 /"

whereas

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
problem.

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?

--Andy