On Tue, Jan 16, 2018 at 05:41:46PM +0100, Miklos Szeredi wrote: > Right. > > Still, those two (propagation and flags) are properties of the mount. > No fundamental difference in how to handle them, that I see. Okay, we > have MS_REC handling in the propagation and not in the flags, but > that's something that might make sense for flags as well. > > What's more interesting is how MS_PRIVATE + MS_REC semantics are > complete failure in the real world: the logical thing would be to mark > a mount private on the supplied mount AND propagate an umount event to > everywhere else. This is utter nonsense. Most of the time it's "Fedora, in its infinite bogo^Wwisdom has made everything shared; I don't fucking need that idiocy, so please unshare this, this and that". You really don't want (or have permissions for) unmounting e.g. /mnt in namespace of init when you do that. Sure, we get tons of bug reports. Due to idiotic Fedora setup, with everything shared. The same setup that would go up in flames on the semantics change you propose. If anything, "private bind on itself" would be a useful operation. Turning given location into a mountpoint, and having everything under it looking as it used to, but with no propagation at all. Without bothering anybody else, even if location currently happens to be on a shared/master mount. I can slap that together for mount(2), but I'm not sure what a sane combination of flags for that would look like ;-) For fsmount I think it would be very useful thing to have. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
