On Fri, Oct 11, 2024 at 07:12:17PM +0900, Tetsuo Handa wrote: > On 2024/10/11 0:26, 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. > > I can't catch what you are trying to do. What is wrong with that? My understanding is that tomoyo_get_attributes() is used to log or expose access requests to user space, including inode numbers. Is that correct? If yes, then the inode numbers might not reflect what user space sees with stat(2). > > > 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. > > Currently, ino_t is 32bits on 32-bit architectures, isn't it? > Why do you need to use 64bits on 32-bit architectures? ino_t is indeed 32 bits on 32-bit architectures, but user space can still get a 64-bit stat->ino value. > > > 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(). > > What does the user space's view of an inode number mean? It's the value user space gets with stat(2). > What does the kernel space's view of an inode number mean? It's struct inode->i_ino and ino_t variables.
