On Wed, May 28, 2025 at 11:57 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > 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); > +1 > 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. > Agree. I will use a different workaround for fstest. Thanks, Amir. > 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
