From: Miklos Szeredi <mszeredi@redhat.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: David Howells <dhowells@redhat.com>,
viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
christian@brauner.io, Jann Horn <jannh@google.com>,
darrick.wong@oracle.com, Linux API <linux-api@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]
Date: Mon, 24 Feb 2020 11:24:51 +0100 [thread overview]
Message-ID: <CAOssrKehjnTwbc6A1VagM5hG_32hy3mXZenx_PdGgcUGxYOaLQ@mail.gmail.com> (raw)
In-Reply-To: <1582316494.3376.45.camel@HansenPartnership.com>
On Fri, Feb 21, 2020 at 9:21 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Fri, 2020-02-21 at 18:01 +0000, David Howells wrote:
> [...]
> > ============================
> > FILESYSTEM INFORMATION QUERY
> > ============================
> >
> > The fsinfo() system call allows information about the filesystem at a
> > particular path point to be queried as a set of attributes, some of
> > which may have more than one value.
> >
> > Attribute values are of four basic types:
> >
> > (1) Version dependent-length structure (size defined by type).
> >
> > (2) Variable-length string (up to 4096, including NUL).
> >
> > (3) List of structures (up to INT_MAX size).
> >
> > (4) Opaque blob (up to INT_MAX size).
> >
> > Attributes can have multiple values either as a sequence of values or
> > a sequence-of-sequences of values and all the values of a particular
> > attribute must be of the same type.
> >
> > Note that the values of an attribute *are* allowed to vary between
> > dentries within a single superblock, depending on the specific dentry
> > that you're looking at, but all the values of an attribute have to be
> > of the same type.
> >
> > I've tried to make the interface as light as possible, so
> > integer/enum attribute selector rather than string and the core does
> > all the allocation and extensibility support work rather than leaving
> > that to the filesystems. That means that for the first two attribute
> > types, the filesystem will always see a sufficiently-sized buffer
> > allocated. Further, this removes the possibility of the filesystem
> > gaining access to the userspace buffer.
> >
> >
> > fsinfo() allows a variety of information to be retrieved about a
> > filesystem and the mount topology:
> >
> > (1) General superblock attributes:
> >
> > - Filesystem identifiers (UUID, volume label, device numbers,
> > ...)
> > - The limits on a filesystem's capabilities
> > - Information on supported statx fields and attributes and IOC
> > flags.
> > - A variety single-bit flags indicating supported capabilities.
> > - Timestamp resolution and range.
> > - The amount of space/free space in a filesystem (as statfs()).
> > - Superblock notification counter.
> >
> > (2) Filesystem-specific superblock attributes:
> >
> > - Superblock-level timestamps.
> > - Cell name.
> > - Server names and addresses.
> > - Filesystem-specific information.
> >
> > (3) VFS information:
> >
> > - Mount topology information.
> > - Mount attributes.
> > - Mount notification counter.
> >
> > (4) Information about what the fsinfo() syscall itself supports,
> > including
> > the type and struct/element size of attributes.
> >
> > The system is extensible:
> >
> > (1) New attributes can be added. There is no requirement that a
> > filesystem implement every attribute. Note that the core VFS
> > keeps a
> > table of types and sizes so it can handle future extensibility
> > rather
> > than delegating this to the filesystems.
> >
> > (2) Version length-dependent structure attributes can be made larger
> > and
> > have additional information tacked on the end, provided it keeps
> > the
> > layout of the existing fields. If an older process asks for a
> > shorter
> > structure, it will only be given the bits it asks for. If a
> > newer
> > process asks for a longer structure on an older kernel, the
> > extra
> > space will be set to 0. In all cases, the size of the data
> > actually
> > available is returned.
> >
> > In essence, the size of a structure is that structure's version:
> > a
> > smaller size is an earlier version and a later version includes
> > everything that the earlier version did.
> >
> > (3) New single-bit capability flags can be added. This is a
> > structure-typed
> > attribute and, as such, (2) applies. Any bits you wanted but
> > the kernel
> > doesn't support are automatically set to 0.
> >
> > fsinfo() may be called like the following, for example:
> >
> > struct fsinfo_params params = {
> > .at_flags = AT_SYMLINK_NOFOLLOW,
> > .flags = FSINFO_FLAGS_QUERY_PATH,
> > .request = FSINFO_ATTR_AFS_SERVER_ADDRESSES,
> > .Nth = 2,
> > };
> > struct fsinfo_server_address address;
> > len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", ¶ms,
> > &address, sizeof(address));
> >
> > The above example would query an AFS filesystem to retrieve the
> > address
> > list for the 3rd server, and:
> >
> > struct fsinfo_params params = {
> > .at_flags = AT_SYMLINK_NOFOLLOW,
> > .flags = FSINFO_FLAGS_QUERY_PATH,
> > .request = FSINFO_ATTR_AFS_CELL_NAME;
> > };
> > char cell_name[256];
> > len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", ¶ms,
> > &cell_name, sizeof(cell_name));
> >
> > would retrieve the name of an AFS cell as a string.
> >
> > In future, I want to make fsinfo() capable of querying a context
> > created by
> > fsopen() or fspick(), e.g.:
> >
> > fd = fsopen("ext4", 0);
> > struct fsinfo_params params = {
> > .flags = FSINFO_FLAGS_QUERY_FSCONTEXT,
> > .request = FSINFO_ATTR_PARAMETERS;
> > };
> > char buffer[65536];
> > fsinfo(fd, NULL, ¶ms, &buffer, sizeof(buffer));
> >
> > even if that context doesn't currently have a superblock attached. I
> > would prefer this to contain length-prefixed strings so that there's
> > no need to insert escaping, especially as any character, including
> > '\', can be used as the separator in cifs and so that binary
> > parameters can be returned (though that is a lesser issue).
>
> 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?
Thanks,
Miklos
next prev parent reply other threads:[~2020-02-24 10:25 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 18:01 [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] David Howells
2020-02-21 18:01 ` [PATCH 01/17] watch_queue: Add security hooks to rule on setting mount and sb watches " David Howells
2020-02-21 18:02 ` [PATCH 02/17] watch_queue: Implement mount topology and attribute change notifications " David Howells
2020-02-21 18:02 ` [PATCH 03/17] watch_queue: sample: Display mount tree " David Howells
2020-02-21 18:02 ` [PATCH 04/17] watch_queue: Introduce a non-repeating system-unique superblock ID " David Howells
2020-02-21 18:02 ` [PATCH 05/17] watch_queue: Add superblock notifications " David Howells
2020-02-21 18:02 ` [PATCH 06/17] watch_queue: sample: Display " David Howells
2020-02-21 18:02 ` [PATCH 07/17] fsinfo: Add fsinfo() syscall to query filesystem information " David Howells
2020-02-26 2:29 ` Aleksa Sarai
2020-02-28 14:44 ` David Howells
2020-02-21 18:02 ` [PATCH 08/17] fsinfo: Provide a bitmap of supported features " David Howells
2020-02-21 18:03 ` [PATCH 09/17] fsinfo: Allow fsinfo() to look up a mount object by ID " David Howells
2020-02-21 18:03 ` [PATCH 10/17] fsinfo: Allow mount information to be queried " David Howells
2020-03-04 14:58 ` Miklos Szeredi
2020-03-04 16:10 ` Miklos Szeredi
2020-02-21 18:03 ` [PATCH 11/17] fsinfo: sample: Mount listing program " David Howells
2020-02-21 18:03 ` [PATCH 12/17] fsinfo: Allow the mount topology propogation flags to be retrieved " David Howells
2020-02-21 18:03 ` [PATCH 13/17] fsinfo: Query superblock unique ID and notification counter " David Howells
2020-02-21 18:03 ` [PATCH 14/17] fsinfo: Add API documentation " David Howells
2020-02-21 18:03 ` [PATCH 15/17] fsinfo: Add support for AFS " David Howells
2020-02-21 18:03 ` [PATCH 16/17] fsinfo: Add example support for Ext4 " David Howells
2020-02-21 18:04 ` [PATCH 17/17] fsinfo: Add example support for NFS " David Howells
2020-02-21 20:21 ` [PATCH 00/17] VFS: Filesystem information and notifications " James Bottomley
2020-02-24 10:24 ` Miklos Szeredi [this message]
2020-02-24 14:55 ` James Bottomley
2020-02-24 15:28 ` Miklos Szeredi
2020-02-25 12:13 ` Steven Whitehouse
2020-02-25 15:28 ` James Bottomley
2020-02-25 15:47 ` Steven Whitehouse
2020-02-26 9:11 ` Miklos Szeredi
2020-02-26 10:51 ` Steven Whitehouse
2020-02-27 5:06 ` Ian Kent
2020-02-27 9:36 ` Miklos Szeredi
2020-02-27 11:34 ` Ian Kent
2020-02-27 13:45 ` Miklos Szeredi
2020-02-27 15:14 ` Karel Zak
2020-02-28 0:43 ` Ian Kent
2020-02-28 8:35 ` Miklos Szeredi
2020-02-28 12:27 ` Greg Kroah-Hartman
2020-02-28 16:24 ` Miklos Szeredi
2020-02-28 17:15 ` Al Viro
2020-03-02 8:43 ` Miklos Szeredi
2020-03-02 10:34 ` Karel Zak
2020-02-28 16:42 ` David Howells
2020-02-28 15:08 ` James Bottomley
2020-02-28 15:40 ` Miklos Szeredi
2020-02-28 0:12 ` Ian Kent
2020-02-28 15:52 ` Christian Brauner
2020-02-28 16:36 ` David Howells
2020-03-02 9:09 ` Miklos Szeredi
2020-03-02 9:38 ` Greg Kroah-Hartman
2020-03-03 5:27 ` Ian Kent
2020-03-03 7:46 ` Miklos Szeredi
2020-03-06 16:25 ` Miklos Szeredi
2020-03-06 19:43 ` Al Viro
2020-03-06 19:54 ` Miklos Szeredi
2020-03-06 19:58 ` Al Viro
2020-03-06 20:05 ` Al Viro
2020-03-06 20:11 ` Miklos Szeredi
2020-03-06 20:37 ` Al Viro
2020-03-06 20:38 ` Al Viro
2020-03-06 20:45 ` Al Viro
2020-03-06 20:49 ` Al Viro
2020-03-06 20:51 ` Miklos Szeredi
2020-03-06 21:28 ` Al Viro
2020-03-06 20:56 ` Al Viro
2020-03-06 20:51 ` Miklos Szeredi
2020-03-07 9:48 ` Greg Kroah-Hartman
2020-03-07 20:48 ` Miklos Szeredi
2020-03-03 9:12 ` David Howells
2020-03-03 9:26 ` Miklos Szeredi
2020-03-03 9:48 ` Miklos Szeredi
2020-03-03 10:21 ` Steven Whitehouse
2020-03-03 10:32 ` Miklos Szeredi
2020-03-03 11:09 ` Ian Kent
2020-03-03 10:00 ` Christian Brauner
2020-03-03 10:13 ` Miklos Szeredi
2020-03-03 10:25 ` Christian Brauner
2020-03-03 11:33 ` Miklos Szeredi
2020-03-03 11:56 ` Christian Brauner
2020-03-03 11:38 ` Karel Zak
2020-03-03 13:03 ` Greg Kroah-Hartman
2020-03-03 13:14 ` Greg Kroah-Hartman
2020-03-03 13:34 ` Miklos Szeredi
2020-03-03 13:43 ` Greg Kroah-Hartman
2020-03-03 14:10 ` Greg Kroah-Hartman
2020-03-03 14:13 ` Jann Horn
2020-03-03 14:24 ` Greg Kroah-Hartman
2020-03-03 15:44 ` Jens Axboe
2020-03-03 16:37 ` Greg Kroah-Hartman
2020-03-03 16:51 ` Jeff Layton
2020-03-03 16:55 ` Jens Axboe
2020-03-03 19:02 ` Jeff Layton
2020-03-03 19:07 ` Jens Axboe
2020-03-03 19:23 ` Jens Axboe
2020-03-03 19:43 ` Jeff Layton
2020-03-03 20:33 ` Jens Axboe
2020-03-03 21:03 ` Jeff Layton
2020-03-03 21:20 ` Jens Axboe
2020-03-03 14:10 ` Miklos Szeredi
2020-03-03 14:29 ` Greg Kroah-Hartman
2020-03-03 14:40 ` Jann Horn
2020-03-03 16:51 ` Greg Kroah-Hartman
2020-03-03 16:57 ` Jann Horn
2020-03-03 20:15 ` Greg Kroah-Hartman
2020-03-03 14:40 ` David Howells
2020-03-04 4:20 ` Ian Kent
2020-03-03 14:19 ` David Howells
2020-03-03 16:59 ` Greg Kroah-Hartman
2020-03-03 14:23 ` Christian Brauner
2020-03-03 15:23 ` Greg Kroah-Hartman
2020-03-03 15:53 ` David Howells
2020-03-04 2:01 ` Ian Kent
2020-03-04 15:22 ` Karel Zak
2020-03-04 16:49 ` Greg Kroah-Hartman
2020-03-04 17:55 ` Karel Zak
2020-03-03 14:09 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOssrKehjnTwbc6A1VagM5hG_32hy3mXZenx_PdGgcUGxYOaLQ@mail.gmail.com \
--to=mszeredi@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=christian@brauner.io \
--cc=darrick.wong@oracle.com \
--cc=dhowells@redhat.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).