linux-kernel - Re: Removing shared subtrees?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVnXXjDjh9+vOGfFh08-wtjJeuC=n=PtNusOS_nq0puFA@mail.gmail.com>
Date:	Mon, 29 Sep 2014 17:36:27 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Removing shared subtrees?

On Mon, Sep 29, 2014 at 5:29 PM, Al Viro <viro@...iv.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/