Re: [PATCH 01/61] vfs: widen inode hash/lookup functions to u64
Jan Kara <[email protected]> Thu, 26 Feb 2026 18:14:45 +0100
| Newsgroups | gmane.linux.file-systems.f2fs,gmane.comp.video.dri.devel,gmane.linux.hams,gmane.comp.file-systems.ceph.devel,gmane.linux.kernel,gmane.linux.kernel.perf.user,gmane.linux.drivers.video-input-infrastructure,gmane.linux.kernel.cifs,gmane.comp.file-systems.nilfs.user,gmane.comp.file-systems.coda.general,gmane.linux.drivers.mtd,gmane.comp.freedesktop.amd-gfx,gmane.linux.kernel.autofs,gmane.linux.nfs,gmane.comp.file-systems.ext4,gmane.linux.kernel.mm,gmane.network.samba.internals,gmane.linux.file-systems,gmane.comp.file-systems.ecryptfs.general,gmane.linux.file-systems.union,gmane.linux.x25,gmane.comp.security.apparmor,gmane.linux.network,gmane.linux.kernel.lsm |
|---|---|
| Message-ID | <hbvcdh2qnimdnbqnayykrcja6et2oyofe5h3s7n4imwbcaqht5@xq576inhcje4> |
On Thu 26-02-26 18:00:36, Jan Kara wrote: > On Thu 26-02-26 10:55:03, Jeff Layton wrote: > > Change the inode hash/lookup VFS API functions to accept u64 parameters > > instead of unsigned long for inode numbers and hash values. This is > > preparation for widening i_ino itself to u64, which will allow > > filesystems to store full 64-bit inode numbers on 32-bit architectures. > > > > Since unsigned long implicitly widens to u64 on all architectures, this > > change is backward-compatible with all existing callers. > > > > Functions updated: > > - hash(), find_inode_fast(), find_inode_by_ino_rcu(), test_inode_iunique() > > - __insert_inode_hash(), iget_locked(), iget5_locked(), iget5_locked_rcu() > > - ilookup(), ilookup5(), ilookup5_nowait() > > - find_inode_nowait(), find_inode_rcu() > > - inode_insert5(), insert_inode_locked4() > > - insert_inode_locked() (local variable) > > - dump_mapping() (local variable and format string) > > > > Signed-off-by: Jeff Layton <[email protected]> > > Looks good. Feel free to add: > > Reviewed-by: Jan Kara <[email protected]> Thinking some more about this (and also seeing the discussion about patch 2) - maybe instead of using explicit u64 we should typedef kino_t as u64 and use that? Honza -- Jan Kara <[email protected]> SUSE Labs, CR