Re: [PATCH v3 00/12] vfs: change inode->i_ino from unsigned long to u64

On Mon, 2026-03-09 at 13:47 -0400, Mimi Zohar wrote:
> [ I/O socket time out.  Trimming the To list.]
>=20
> 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 patc=
h
> > 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.
> >=20
> > The entire pile is in the "iino-u64" branch of my tree, if anyone is
> > interested in testing this.
> >=20
> >     https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> >=20
> > Original cover letter follows:
> >=20
> > ----------------------8<-----------------------
> >=20
> > Christian said [1] to "just do it" when I proposed this, so here we are=
!
> >=20
> > 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 fo=
r
> > an inode.
> >=20
> > 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.
> >=20
> > The bulk of the changes are to format strings and tracepoints, since th=
e
> > 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.
> >=20
> > 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.
> >=20
> > 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=
.
> >=20
> > [1]: https://lore.kernel.org/linux-fsdevel/20260219-portrait-winkt-9590=
70cee42f@brauner/
> >=20
> > Signed-off-by: Jeff Layton <[email protected]>
>=20
> 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.=20
>=20
>=20

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/e=
vm_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, stru=
ct inode *inode,
                          char type, char *digest)
 {
        struct h_misc {
-               unsigned long ino;
+               u64 ino;
                __u32 generation;
                uid_t uid;
                gid_t gid;



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?

Thanks,
--=20
Jeff Layton <[email protected]>