Received-SPF: pass (google.com: domain of linux-nfs+bounces-3442-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 28 May 2024 06:22:23 -0700
From: Christoph Hellwig <hch@infradead.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Chuck Lever <chuck.lever@oracle.com>,
	Jeff Layton <jlayton@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Alexander Aring <alex.aring@gmail.com>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
 name_to_handle_at(2)
Message-ID: <ZlXaj9Qv0bm9PAjX@infradead.org>
References: <ZlMADupKkN0ITgG5@infradead.org>
 <20240526.184753-detached.length.shallow.contents-jWkMukeD7VAC@cyphar.com>
 <ZlRy7EBaV04F2UaI@infradead.org>
 <20240527133430.ifjo2kksoehtuwrn@quack3>
 <ZlSzotIrVPGrC6vt@infradead.org>
 <20240528-wachdienst-weitreichend-42f8121bf764@brauner>
 <ZlWVkJwwJ0-B-Zyl@infradead.org>
 <20240528-gesell-evakuieren-899c08cbfa06@brauner>
 <ZlW4IWMYxtwbeI7I@infradead.org>
 <20240528-gipfel-dilemma-948a590a36fd@brauner>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240528-gipfel-dilemma-948a590a36fd@brauner>

On Tue, May 28, 2024 at 02:04:16PM +0200, Christian Brauner wrote:
> Can you please explain how opening an fd based on a handle returned from
> name_to_handle_at() and not using a mount file descriptor for
> open_by_handle_at() would work?

Same as NFS file handles:

name_to_handle_at returns a handle that includes a file system
identifier.

open_by_handle_at looks up the superblock based on that identifier.

For the identifier I could imagin three choices:

 1) use the fsid as returned in statfs and returned by fsnotify.
    The downside is that it is "only" 64-bit.  The upside is that
    we have a lot of plumbing for it
 2) fixed 128-bit identifier to provide more entropy
 3) a variable length identifier, which is more similar to NFS,
    but also a lot more complicated

We'd need a global lookup structure to find the sb by id.  The simplest
one would be a simple linear loop over super_blocks which isn't terribly
efficient, but probably better than whatever userspace is doing to
find a mount fd right now.

Let me cook up a simple prototype for 1) as it shouldn't be more than
a few hundred lines of code.