On Mon, Oct 14, 2024 at 04:47:17PM +0200, Christian Brauner wrote: > On Thu, Oct 10, 2024 at 05:26:41PM +0200, Mickaël Salaün wrote: > > When a filesystem manages its own inode numbers, like NFS's fileid shown > > to user space with getattr(), other part of the kernel may still expose > > the private inode->ino through kernel logs and audit. > > > > Another issue is on 32-bit architectures, on which ino_t is 32 bits, > > whereas the user space's view of an inode number can still be 64 bits. > > > > Add a new inode_get_ino() helper calling the new struct > > inode_operations' get_ino() when set, to get the user space's view of an > > inode number. inode_get_ino() is called by generic_fillattr(). > > I mean, you have to admit that this is a pretty blatant hack and that's > not worthy of a separate inode method, let alone the potential > performance implication that multiple people already brought up. My initial approach was to use u64 for struct inode's i_ino, but I realized it had too much implications on potentially all filesystems and other parts of the kernel. I'm sure they are much more legitimate folks to handle this transition. I'd be curious to know how such i_ino type change could be backported though.
