On 2/27/26 00:55, 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]>

[...]

> -int insert_inode_locked4(struct inode *inode, unsigned long hashval,
> +int insert_inode_locked4(struct inode *inode, u64 hashval,
>               int (*test)(struct inode *, void *), void *data)
>  {
>       struct inode *old;
> @@ -2642,7 +2642,7 @@ void init_special_inode(struct inode *inode, umode_t 
> mode, dev_t rdev)
>               break;
>       default:
>               printk(KERN_DEBUG "init_special_inode: bogus i_mode (%o) for"
> -                               " inode %s:%lu\n", mode, inode->i_sb->s_id,
> +                               " inode %s:%llu\n", mode, inode->i_sb->s_id,

Hmmm. the type of ino in struct inode is changed in patch 2, not this patch. So
this feels incorrect. Why not just squash patch 2 in here ?

While at it, maybe you could change this to use pr_debug() too ?

-- 
Damien Le Moal
Western Digital Research

Reply via email to