On Fri, Oct 11, 2024 at 07:54:58PM +0900, Tetsuo Handa wrote: > On 2024/10/11 19:12, Tetsuo Handa wrote: > > On 2024/10/11 0:26, Mickaël Salaün wrote: > >> 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? > > Changing from 32bits to 64bits for communicating with userspace programs > breaks userspace programs using "ino_t" (or "unsigned long") for handling > inode numbers, doesn't it? Attempt to change from %lu to %llu will not be > acceptable unless the upper 32bits are guaranteed to be 0 on 32-bit > architectures. > > Since syslogd/auditd are not the only programs that parse kernel logs and > audit logs, updating only syslogd/auditd is not sufficient. We must not break > existing userspace programs, and thus we can't change the format string. This might only break user space that wrongfully uses 32-bit variables to store 64-bit values. According to the UAPI, inode numbers should be 64 bits.
