On Mon, 2026-03-09 at 15:00 -0400, Mimi Zohar wrote: > On Mon, 2026-03-09 at 13:59 -0400, Jeff Layton wrote: > > On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote: > > > [ I/O socket time out. Trimming the To list.] > > > > > > On Wed, 2026-03-04 at 10:32 -0500, Jeff Layton wrote: > > > > This version squashes all of the format-string changes and the i_ino > > > > type change into the same patch. This results in a giant 600+ line patch > > > > at the end of the series, but it does remain bisectable. Because the > > > > patchset was reorganized (again) some of the R-b's and A-b's have been > > > > dropped. > > > > > > > > The entire pile is in the "iino-u64" branch of my tree, if anyone is > > > > interested in testing this. > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/ > > > > > > > > Original cover letter follows: > > > > > > > > ----------------------8<----------------------- > > > > > > > > Christian said [1] to "just do it" when I proposed this, so here we are! > > > > > > > > For historical reasons, the inode->i_ino field is an unsigned long, > > > > which means that it's 32 bits on 32 bit architectures. This has caused a > > > > number of filesystems to implement hacks to hash a 64-bit identifier > > > > into a 32-bit field, and deprives us of a universal identifier field for > > > > an inode. > > > > > > > > This patchset changes the inode->i_ino field from an unsigned long to a > > > > u64. This shouldn't make any material difference on 64-bit hosts, but > > > > 32-bit hosts will see struct inode grow by at least 4 bytes. This could > > > > have effects on slabcache sizes and field alignment. > > > > > > > > The bulk of the changes are to format strings and tracepoints, since the > > > > kernel itself doesn't care that much about the i_ino field. The first > > > > patch changes some vfs function arguments, so check that one out > > > > carefully. > > > > > > > > With this change, we may be able to shrink some inode structures. For > > > > instance, struct nfs_inode has a fileid field that holds the 64-bit > > > > inode number. With this set of changes, that field could be eliminated. > > > > I'd rather leave that sort of cleanups for later just to keep this > > > > simple. > > > > > > > > Much of this set was generated by LLM, but I attributed it to myself > > > > since I consider this to be in the "menial tasks" category of LLM usage. > > > > > > > > [1]: > > > > https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-959070cee42f@brauner/ > > > > > > > > Signed-off-by: Jeff Layton <[email protected]> > > > > > > Jeff, missing from this patch set is EVM. In hmac_add_misc() EVM copies > > > the > > > i_ino and calculates either an HMAC or file meta-data hash, which is then > > > signed. > > > > > > > > > > Thanks Mimi, good catch. > > > > It looks like we should just be able to change the ino field to a u64 > > alongside everything else. Something like this: > > > > diff --git a/security/integrity/evm/evm_crypto.c > > b/security/integrity/evm/evm_crypto.c > > index c0ca4eedb0fe..77b6c2fa345e 100644 > > --- a/security/integrity/evm/evm_crypto.c > > +++ b/security/integrity/evm/evm_crypto.c > > @@ -144,7 +144,7 @@ static void hmac_add_misc(struct shash_desc *desc, > > struct inode *inode, > > char type, char *digest) > > { > > struct h_misc { > > - unsigned long ino; > > + u64 ino; > > __u32 generation; > > uid_t uid; > > gid_t gid; > > > > Agreed. > > > > > That should make no material difference on 64-bit hosts. What's the > > effect on 32-bit? Will they just need to remeasure everything or would > > the consequences be more dire? Do we have any clue whether anyone is > > using EVM in 32-bit environments? > > All good questions. Unfortunately I don't know the answer to most of them. > What > we do know: changing the size of the i_ino field would affect EVM file > metadata > verification and would require relabeling the filesystem. Even packages > containing EVM portable signatures, which don't include or verify the i_ino > number, would be affected. >
Ouch. Technically, I guess this is ABI... While converting to u64 seems like the ideal thing to do, the other option might be to just keep this as an unsigned long for now. No effect on 64-bit, but that could keep things working 32-bit when the i_ino casts properly to a u32. ext4 would be fine since they don't issue inode numbers larger than UINT_MAX. xfs and btrfs are a bit more iffy, but worst case they'd just need to be relabeled (which is what they'll need to do anyway). If we do that, then we should probably add a comment to this function explaining why it's an unsigned long. Thoughts? -- Jeff Layton <[email protected]>
