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