Message-ID: <1c8db4e2b707f958316941d8edd2073ee7e7b22c.camel@themaw.net>
Date:   Thu, 27 Feb 2020 13:06:37 +0800
From:   Ian Kent <raven@...maw.net>
To:     Miklos Szeredi <mszeredi@...hat.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Steven Whitehouse <swhiteho@...hat.com>,
        Miklos Szeredi <miklos@...redi.hu>,
        David Howells <dhowells@...hat.com>,
        viro <viro@...iv.linux.org.uk>,
        Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...gle.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications
 [ver #17]

On Wed, 2020-02-26 at 10:11 +0100, Miklos Szeredi wrote:
> On Tue, Feb 25, 2020 at 4:29 PM James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> 
> > The other thing a file descriptor does that sysfs doesn't is that
> > it
> > solves the information leak: if I'm in a mount namespace that has
> > no
> > access to certain mounts, I can't fspick them and thus I can't see
> > the
> > information.  By default, with sysfs I can.
> 
> That's true, but procfs/sysfs has to deal with various namespacing
> issues anyway.  If this is just about hiding a number of entries,
> then
> I don't think that's going to be a big deal.

I didn't see name space considerations in sysfs when I was looking at
it recently. Obeying name space requirements is likely a lot of work
in sysfs.

> 
> The syscall API is efficient: single syscall per query instead of
> several, no parsing necessary.
> 
> However, it is difficult to extend, because the ABI must be updated,
> possibly libc and util-linux also, so that scripts can also consume
> the new parameter.  With the sysfs approach only the kernel needs to
> be updated, and possibly only the filesystem code, not even the VFS.
> 
> So I think the question comes down to:  do we need a highly efficient
> way to query the superblock parameters all at once, or not?

Or a similar question could be, how could a sysfs interface work
to provide mount information.

Getting information about all mounts might not be too bad but the
sysfs directory structure that would be needed to represent all
system mounts (without considering name spaces) would likely
result in somewhat busy user space code.

For example, given a path, and the path is all I know, how do I
get mount information?

Ignoring possible multiple mounts on a mount point, call fsinfo()
with the path and get the id (the path walk is low overhead) to
use with fsinfo() to get the all the info I need ... done.

Again, ignoring possible multiple mounts on a mount point, and
assuming there is a sysfs tree enumerating all the system mounts.
I could open <sysfs base> + mount point path followed buy opening
and reading the individual attribute files ... a bit more busy
that one ... particularly if I need to do it for several thousand
mounts.

Then there's the code that would need to be added to maintain the
various views in the sysfs tree, which can't be restricted only to
the VFS because there's file system specific info needed too (the
maintain a table idea), and that's before considering name space
handling changes to sysfs.

At the least the question of "do we need a highly efficient way
to query the superblock parameters all at once" needs to be
extended to include mount table enumeration as well as getting
the info.

But this is just me thinking about mount table handling and the
quite significant problem we now have with user space scanning
the proc mount tables to get this information.

Ian

Powered by blists - more mailing lists