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