On Tue, Jan 16, 2018 at 4:40 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > Miklos Szeredi <mszeredi@xxxxxxxxxx> wrote: > >> > (6) Adjust a mountpoint's topology flags: >> > >> > mount_set_topology(int dfd, const char *path, >> > unsigned int topology_flags); >> > >> > (7) Reconfigure a mountpoint: >> > >> > mount_reconfigure(int dfd, const char *path, >> > unsigned int mount_flags); >> >> >> What's the fundamental difference between topology flags and other >> flags? Why two syscalls? > > Actually, if you look at the do_mount() function, these *are* separate > things. If you look at the code: > > if (flags & MS_REMOUNT) > retval = do_remount(&path, flags, sb_flags, mnt_flags, > data_page); > > ^^^ that is mount_reconfigure() and superblock reconfiguration. > > else if (flags & MS_BIND) > retval = do_loopback(&path, dev_name, flags & MS_REC); > else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE)) > retval = do_change_type(&path, flags); > > ^^^ that is mount_set_topology(). > > else if (flags & MS_MOVE) > retval = do_move_mount(&path, dev_name); > else > retval = do_new_mount(&path, type_page, sb_flags, mnt_flags, > dev_name, data_page); > > The mount() syscall is actually a function switch with five functions. 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. But that's not what we do, we completely mess up propagation that can result in millions of "leaked" mounts. I've seen multiple bug reports where this illogical behavior fooled people. It can be worked around, of course, but maybe we should fix this on the new interface and allow a sane private setting. Thanks, Miklos > > David -- 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
