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: Mon, 27 May 2024 15:38:40 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "hch@...radead.org" <hch@...radead.org>
CC: "jack@...e.cz" <jack@...e.cz>, "chuck.lever@...cle.com"
	<chuck.lever@...cle.com>, "linux-api@...r.kernel.org"
	<linux-api@...r.kernel.org>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "brauner@...nel.org" <brauner@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"alex.aring@...il.com" <alex.aring@...il.com>, "cyphar@...har.com"
	<cyphar@...har.com>, "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"jlayton@...nel.org" <jlayton@...nel.org>, "amir73il@...il.com"
	<amir73il@...il.com>, "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>
Subject: Re: [PATCH RFC v2] fhandle: expose u64 mount id to
 name_to_handle_at(2)

On Mon, 2024-05-27 at 04:49 -0700, hch@...radead.org wrote:
> On Sun, May 26, 2024 at 10:32:39PM +0000, Trond Myklebust wrote:
> > I assume the reason is to give the caller a race free way to figure
> > out
> > which submount the path resolves to.
> 
> But the handle op are global to the file systems (aka super_block). 
> It
> does not matter what mount you use to access it.

Sure. However if you are providing a path argument, then presumably you
need to know which file system (aka super_block) it eventually resolves
to.

> 
> Snip random things about userland NFS servers I couldn't care less
> about..
> 

My point was that at least for that case, you are better off using a
file descriptor and not having to care about the mount id.

If your use case isn't NFS servers, then what use case are you
targeting, and how do you expect those applications to use this API?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com