On Wed, May 28, 2025 at 11:56:48AM +0200, Miklos Szeredi 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
Well, in this case it uses mountinfo
> 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.
This is how mount(8) works for decades, and I do not like it, but ...
The problem is something else.
Do you see the paradox? The suggested LIBMOUNT_FORCE_MOUNT2 workaround
just switches to mount(2), but everything else remains the same; it
sends all the mount options to the kernel.
Why is it fine for mount(2) but wrong for fsconfig()? This is the
question. There is an incompatibility between the APIs.
> 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);
The classic MS_REMOUNT has been interpreted for decades as "replace"
mount option, not just "replace only specified". This is why mount(8)
sends all options on remount.
However, "remount,ro" is such a common and specific use case that
perhaps we can make an exception and focus only on "ro".
> 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.
I sent straces; fsconfig() doesn't accept the options, but
mount(MS_REMOUNT) does. Why blame libmount?
We can change how libmount works with fstab on remount, but it will
just hide, not resolve, the problem with fsconfig().
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
