Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
        Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
        Kingdom.
        Registered in England and Wales under Company Registration No. 3798903
From:   David Howells <dhowells@redhat.com>
In-Reply-To: <20200228155244.k4h4hz3dqhl7q7ks@wittgenstein>
References: <20200228155244.k4h4hz3dqhl7q7ks@wittgenstein> <158230810644.2185128.16726948836367716086.stgit@warthog.procyon.org.uk> <1582316494.3376.45.camel@HansenPartnership.com> <CAOssrKehjnTwbc6A1VagM5hG_32hy3mXZenx_PdGgcUGxYOaLQ@mail.gmail.com> <1582556135.3384.4.camel@HansenPartnership.com> <CAJfpegsk6BsVhUgHNwJgZrqcNP66wS0fhCXo_2sLt__goYGPWg@mail.gmail.com> <a657a80e-8913-d1f3-0ffe-d582f5cb9aa2@redhat.com> <1582644535.3361.8.camel@HansenPartnership.com>
To:     Christian Brauner <christian.brauner@ubuntu.com>
Cc:     dhowells@redhat.com,
        James Bottomley <James.Bottomley@HansenPartnership.com>,
        Steven Whitehouse <swhiteho@redhat.com>,
        Miklos Szeredi <miklos@szeredi.hu>,
        Miklos Szeredi <mszeredi@redhat.com>,
        viro <viro@zeniv.linux.org.uk>, Ian Kent <raven@themaw.net>,
        Christian Brauner <christian@brauner.io>,
        Jann Horn <jannh@google.com>,
        "Darrick J. Wong" <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]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <107665.1582907766.1@warthog.procyon.org.uk>
Date:   Fri, 28 Feb 2020 16:36:06 +0000
Message-ID: <107666.1582907766@warthog.procyon.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

sysfs also has some other disadvantages for this:

 (1) There's a potential chicken-and-egg problem in that you have to create a
     bunch of files and dirs in sysfs for every created mount and superblock
     (possibly excluding special ones like the socket mount) - but this
     includes sysfs itself.  This might work - provided you create sysfs
     first.

 (2) sysfs is memory intensive.  The directory structure has to be backed by
     dentries and inodes that linger as long as the referenced object does
     (procfs is more efficient in this regard for files that aren't being
     accessed).

 (3) It gives people extra, indirect ways to pin mount objects and
     superblocks.

For the moment, fsinfo() gives you three ways of referring to a filesystem
object:

 (a) Directly by path.

 (b) By path associated with an fd.

 (c) By mount ID (perm checked by working back up the tree).

but will need to add:

 (d) By fscontext fd (which is hard to find in sysfs).  Indeed, the superblock
     may not even exist yet.

David