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

[Jeff Layton]

On Thu, 2026-02-26 at 11:40 -0500, Mathieu Desnoyers wrote:
> 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.
> 

My worry here is that ino_t is a UAPI type, and I don't think we can
change it there. I think we'll need a new (kernel-internal) typedef
just for this.

> > 
> > 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.
> 

Definitely. None of that would be trustworthy in the middle of the
series.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>