Re: [PATCH 1/4] nfs: store the full NFS fileid in inode->i_ino

On Tue, Jun 23, 2026 at 07:04:47AM -0400, Jeff Layton wrote:
> On Mon, 2026-06-22 at 18:38 -0400, Jeff Layton wrote:

> > Note that it's trying to stuff the inode number field into an unsigned
> > long. Before this patch, the maps file would have printed the old
> > (hashed) inode number on 32-bit. Now, it prints the full 64-bit inode
> > number.

...

> > We could argue that this is a bug in the testcase. It assumes that the
> > maps file will never print a value larger than ULONG_MAX in that field,
> > and I don't see why it would make that assumption in this day and age.

It wouldn't be the first LTP test that had a bug in it.

> > Are there actual programs in the field that scrape the maps file that
> > might be affected by this change?

Not to my knowledge.

> This testcase patch should fix it. I'll plan to send this to the LTP
> list, but it would be nice if someone could confirm the fix on arm32:

I'll try to give it a spin, though my test setup for LTP makes that very
awkward (it's embedded into a rootfs image and built as part of that) so
I wouldn't wait for me.

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmo6iUkACgkQJNaLcl1U
h9A5cwf9Hekd7kCTtmqpWZH1v1u6jPEWUPfz6VaK2grID5e84/eJiUMz9hCXCy2v
gAHRtG8YVxQrE02k02diOI/w2jImue8e0RuCuEg3P74boYuKCNPDdOL9AjdtRKeC
E9SkUS16cTL4Gt+ud+Hbe1gsKCBLQh8fudWJs8XMWWBzMT2WmI6hWN1aX2/McgNi
PTIqM8Ev8tKWMt3pGdjJptNjV2gDlibSwHQQSSdeZJRfxvrLjsfl5StziTH8wNWc
+3610yar/+xzcnmGCxTz+MQwdU8W/i9sfPgE30WchOu4ONut5dEU8d9XflWxi65W
l88dW+LY9Rx2ihKzoM8HrLempQ5ONw==
=Yh0u
-----END PGP SIGNATURE-----