Re: [PATCH] vfs: Don't reject unknown parameters

From: Miklos Szeredi
Date: Fri Dec 13 2019 - 04:15:16 EST


On Thu, Dec 12, 2019 at 10:36 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:

> So you could bloody well just leave recognition (and handling) of "source"
> to the caller, leaving you with just this:
>
> if (strcmp(param->key, "source") == 0)
> return -ENOPARAM;
> /* Just log an error for backwards compatibility */
> errorf(fc, "%s: Unknown parameter '%s'", fc->fs_type->name, param->key);
> return 0;

Which is fine for the old mount(2) interface.

But we have a brand new API as well; do we really need to carry these
backward compatibility issues forward? I mean checking if a
param/flag is supported or not *is* useful and lacking that check is
the source of numerous headaches in legacy interfaces (just take the
open(2) example and the introduction of O_TMPFILE).

Just need a flag in fc indicating if this option comes from the old interface:

if (strcmp(param->key, "source") == 0)
return -ENOPARAM;
/* Just log an error for backwards compatibility */
errorf(fc, "%s: Unknown parameter '%s'", fc->fs_type->name,
param->key);
return fc->legacy ? 0 : -ENOPARAM;

And TBH, I think that logic applies to the common flags as well. Some
of these simply make no sense on the new interface ("silent",
"posixacl") and some are ignored for lots of filesystems ("sync",
"dirsync", "mand", "lazytime"). It would also be nice to reject "rw"
for read-only filesystems.

I have sent patches for the above numerous times, all been ignored by
DavidH and Al. While this seems minor now, I think getting this
interface into a better shape as early as possible may save lots more
headaches later...

Thanks,
Miklos