On Mon, 2020-02-24 at 11:24 +0100, Miklos Szeredi wrote:

On Fri, Feb 21, 2020 at 9:21 PM James Bottomley
[off-list ref] wrote:

[...]

quoted

Could I make a suggestion about how this should be done in a way
that doesn't actually require the fsinfo syscall at all: it could
just be done with fsconfig.  The idea is based on something I've
wanted to do for configfd but couldn't because otherwise it
wouldn't substitute for fsconfig, but Christian made me think it
was actually essential to the ability of the seccomp and other
verifier tools in the critique of configfd and I belive the same
critique applies here.

Instead of making fsconfig functionally configure ... as in you
pass the attribute name, type and parameters down into the fs
specific handler and the handler does a string match and then
verifies the parameters and then acts on them, make it table
configured, so what each fstype does is register a table of
attributes which can be got and optionally set (with each attribute
having a get and optional set function).  We'd have multiple tables
per fstype, so the generic VFS can register a table of attributes
it understands for every fstype (things like name, uuid and the
like) and then each fs type would register a table of fs specific
attributes following the same pattern. The system would examine the
fs specific table before the generic one, allowing
overrides.  fsconfig would have the ability to both get and
set attributes, permitting retrieval as well as setting (which is
how I get rid of the fsinfo syscall), we'd have a global parameter,
which would retrieve the entire table by name and type so the whole
thing is introspectable because the upper layer knows a-priori all
the attributes which can be set for a given fs type and what type
they are (so we can make more of the parsing generic).  Any
attribute which doesn't have a set routine would be read only and
all attributes would have to have a get routine meaning everything
is queryable.

And that makes me wonder: would a
"/sys/class/fs/$ST_DEV/options/$OPTION" type interface be feasible
for this?

Once it's table driven, certainly a sysfs directory becomes possible. 
The problem with ST_DEV is filesystems like btrfs and xfs that may have
multiple devices.  The current fsinfo takes a fspick'd directory fd so
the input to the query is a path, which gets messy in sysfs, although I
could see something like /sys/class/fs/mount/<path>/$OPTION working.

James