Received-SPF: pass (google.com: domain of linux-nfs+bounces-3433-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 28 May 2024 01:28:00 -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: <ZlWVkJwwJ0-B-Zyl@infradead.org>
References: <20240523-exportfs-u64-mount-id-v2-1-f9f959f17eb1@cyphar.com>
 <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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240528-wachdienst-weitreichend-42f8121bf764@brauner>

On Tue, May 28, 2024 at 10:20:21AM +0200, Christian Brauner wrote:
> > This would solve all the problems in this proposal as well as all the
> > obvious ones it doesn't solve.
> 
> As I've said multiple times on the thread I agree that this is what we
> should do next and I would be happy to take patches for this. But
> exposing the 64bit mount id doesn't impede or complicate that work. It's
> a simple and useful addition that can be done now and doesn't prevent us
> from doing the proposed work.

I really confuses the user story as we now have not only one but two
broken modes for the open by handle ops.  We just further go down the
rabbit hole of mixing a non-persistent identifiers with a persistent
one.

> Hell, if you twist my arm I'll even write the patches for this.

I'm also happy to help with that despite very limited time, but I'd
rather avoid doing the misguided mount ID thing.