Re: [PATCH 02/61] vfs: change i_ino from unsigned long to u64

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-02-26 11:35, Jeff Layton wrote:
> On Thu, 2026-02-26 at 11:16 -0500, Mathieu Desnoyers wrote:
>> On 2026-02-26 10:55, Jeff Layton wrote:
>>> Change the type of i_ino in struct inode from unsigned long to u64.
>>>
>>> On 64-bit architectures, unsigned long is already 64 bits, so this is
>>> effectively a type alias change with no runtime impact. On 32-bit
>>> architectures, this widens i_ino from 32 to 64 bits, allowing
>>> filesystems like NFS, CIFS, XFS, Ceph, and FUSE to store their native
>>> 64-bit inode numbers without folding/hashing.
>>>
>>> The VFS already handles 64-bit inode numbers in kstat.ino (u64) and
>>> statx.stx_ino (__u64). The existing overflow checks in cp_new_stat(),
>>> cp_old_stat(), and cp_compat_stat() handle narrowing to 32-bit st_ino
>>> with -EOVERFLOW, so userspace ABI is preserved.
>>>
>>> struct inode will grow by 4 bytes on 32-bit architectures.
>>
>> Changing this type first without changing its associated format strings
>> breaks git bisect.
>>
>> One alternative would be to introduce something like the PRIu64 macro
>> but for printing inode values. This would allow gradually introducing
>> the change without breaking the world as you do so.
>>
>>
> 
> True, but it makes all of the format strings even harder to read. After
> the conversion, we could go back and eliminate the macro though and it
> would keep things more bisectable. I'm not sure what to do about
> tracepoints though. I guess we could declare a new typedef and change
> its definition when i_ino's type changes?

For tracepoints there are two things: a TP_printk format string (which
would be handled by a new pretty printing macro similar to PRIu64), and
the type used within TP_STRUCT__entry. I don't see why you'd need to
change from ino_t to u64 there. The conversion will happen when you flip
the ino_t typedef from unsigned long to u64.

> 
> I'll let others chime in first, but I'm open to going back and doing it
> that way if we don't want to live with the compiler warnings during a
> bisect.

On 32-bit archs, I suspect it will do more than emit compiler warnings.
Trying to boot a kernel in the middle of the series is likely to lead to
interesting inode value printout results.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com