[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49b6c50a50e517b6eb61d40af6fd1fd6e9c09cb2.camel@hammerspace.com>
Date: Mon, 27 May 2024 15:47:33 +0000
From: Trond Myklebust <trondmy@...merspace.com>
To: "brauner@...nel.org" <brauner@...nel.org>, "hch@...radead.org"
<hch@...radead.org>
CC: "jack@...e.cz" <jack@...e.cz>, "chuck.lever@...cle.com"
<chuck.lever@...cle.com>, "linux-fsdevel@...r.kernel.org"
<linux-fsdevel@...r.kernel.org>, "linux-api@...r.kernel.org"
<linux-api@...r.kernel.org>, "alex.aring@...il.com" <alex.aring@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"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 15:17 +0200, Christian Brauner wrote:
>
> Returning the 64bit mount id makes this race-free because we now have
> statmount():
>
> u64 mnt_id = 0;
> name_to_handle_at(AT_FDCWD, "/path/to/file", &handle, &mnt_id, 0);
> statmount(mnt_id);
>
> Which gets you the device number which one can use to figure out the
> uuid without ever having to open a single file (We could even expose
> the
> UUID of the filesystem through statmount() if we wanted to.).
>
It is not race free. statmount() depends on the filesystem still being
mounted somewhere in your namespace, which is not guaranteed above.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@...merspace.com
Powered by blists - more mailing lists