[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241113003729.GF9421@frogsfrogsfrogs>
Date: Tue, 12 Nov 2024 16:37:29 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Erin Shepherd <erin.shepherd@....eu>
Cc: Jeff Layton <jlayton@...nel.org>,
Christian Brauner <brauner@...nel.org>,
Amir Goldstein <amir73il@...il.com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, christian@...uner.io,
paul@...l-moore.com, bluca@...ian.org,
Chuck Lever <chuck.lever@...cle.com>
Subject: Re: [PATCH 0/4] pidfs: implement file handle support
On Tue, Nov 12, 2024 at 11:43:13PM +0100, Erin Shepherd wrote:
> On 12/11/2024 14:57, Jeff Layton wrote:
> > On Tue, 2024-11-12 at 14:10 +0100, Christian Brauner wrote:
> > We should really just move to storing 64-bit inode numbers internally
> > on 32-bit machines. That would at least make statx() give you all 64
> > bits on 32-bit host.
>
> I think that would be ideal from the perspective of exposing it to
> userspace.
> It does leave the question of going back from inode to pidfd unsolved
> though.I like the name_to_handle_at/open_by_handle_at approach because
> it neatly solves both sides of the problem with APIs we already have and
> understand
>
> > Hmm... I guess pid namespaces don't have a convenient 64-bit ID like
> > mount namespaces do? In that case, stashing the pid from init_ns is
> > probably the next best thing.
>
> Not that I could identify, no; so stashing the PID seemed like the most
> pragmatic
> approach.
>
> I'm not 100% sure it should be a documented property of the file
> handle format; I somewhat think that everything after the PID inode
> should be opaque to userspace and subject to change in the future (to
> the point I considered xoring it with a magic constant to make it less
> obvious to userspace/make it more obvious that its not to be relied
> upon; but that to my knowledge is not something that the kernel has
> done elsewhere).
It's a handle, the internal details of its layout of it is supposed to
be opaque to userspace. I wonder how well userspace deals with weirdly
sized handles though...
--D
> - Erin
>
>
Powered by blists - more mailing lists