On 3/6/24 6:17 AM, Christian Brauner wrote: > 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. Oh, right - the problem is the new mount API rejects unknown options internally, right? >>> 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. Ok, good point. Just thinking out loud, I guess an fsopen/fspick flag does make more sense than i.e. each filesystem deciding whether it should reject unknown options in its ->init_fs_context(), for consistency? Right now it looks like the majority of filesystems do reject unknown options internally, already. (To muddy the waters more, other inconsistencies I've thought about are re: how the fileystem handles remount. For example, which options are remountable and which are not, and should non-remountable options fail? Also whether the filesystem internally preserves the original set of options and applies the new set as a delta, or whether it treats the new set as the exact set of options requested post-remount, but that's probably a topic for another day.) -Eric
