linux-kernel - Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 28 May 2024 11:17:58 +0200
From: Christian Brauner <brauner@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jan Kara <jack@...e.cz>, Aleksa Sarai <cyphar@...har.com>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Chuck Lever <chuck.lever@...cle.com>, 
	Jeff Layton <jlayton@...nel.org>, Amir Goldstein <amir73il@...il.com>, 
	Alexander Aring <alex.aring@...il.com>, linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
 name_to_handle_at(2)

> > 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.

As I've said earlier, independent of the new handle type returning the
new mount id is useful and needed because it allows the caller to
reliably generate a mount fd for use with open_by_handle_at() via
statmount(). That won't be solved by a new handle type and is racy with
the old mount id. So I intend to accept a version of this patch.