On Wed, 28 May 2025 at 10:47, Karel Zak <kzak@xxxxxxxxxx> wrote: > Anyway, I agree that this semantics sucks, and from my point of view, > the best approach would be to introduce a new mount(8) command line > semantics to reflect the new kernel API, something like: > > mount modify [--clear noexec] [--set nodev,ro] [--make-private] [--recursive] /mnt > mount reconfigure data=journal,errors=continue,foo,bar /mnt > > and do not include options from fstab in this by default. But there's no fstab entry in the testcase. The no-fstab case likely gets way more use in real life then remounting something in fstab. And this should not need to get the current options from the kernel, since the kernel is the source of the current options. With the KISS principle in mind the non-fstab "mount -oremount,ro /mnt/foo" should just be translated into: fd = fspick(AT_FDCWD, "/mnt/foo", 0); fsconfig(fd, FSCONFIG_SET_FLAG, "ro", NULL, 0); fsconfig(fd, FSCONFIG_CMD_RECONFIGURE, NULL, NULL, 0); and the kernel should take care of the rest. I assume this doesn't generally work, which is a pity, but I'd still think about salvaging the concept. > So, you do not need LIBMOUNT_FORCE_MOUNT2= workaround, use > "--options-mode ignore" or source and target ;-) Yeah, that's definitely a better workaround. I wouldn't call it a fix, since "mount -oremount,ro /overlay" still doesn't work the way it is supposed to, and the thought of adding code to the kernel to work around the current libmount behavior makes me go bleah. Thanks, Miklos
