On Wed, Mar 06, 2024 at 01:13:05PM +0100, Miklos Szeredi wrote: > On Wed, 6 Mar 2024 at 11:57, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > There's a tiny wrinkle though. We currently have no way of letting > > userspace know whether a filesystem supports the new mount API or not > > (see that mount option probing systemd does we recently discussed). So > > if say mount(8) remounts debugfs with mount options that were ignored in > > the old mount api that are now rejected in the new mount api users now > > see failures they didn't see before. > > > > For the user it's completely intransparent why that failure happens. For > > them nothing changed from util-linux's perspective. So really, we should > > probably continue to ignore old mount options for backward compatibility. > > The reject behavior could be made conditional on e.g. an fsopen() flag. and fspick() which I think is more relevant. > > I.e. FSOPEN_REJECT_UNKNOWN would make unknown options be always > rejected. Without this flag fsconfig(2) would behave identically > before/after the conversion. Yeah, that would work. That would only make sense if we make all filesystems reject unknown mount options by default when they're switched to the new mount api imho. When we recognize the request comes from the old mount api fc->oldapi we continue ignoring as we did before. If it comes from the new mount api we reject unless FSOPEN/FSPICK_REJECT_UKNOWN was specified.
