Re: [PATCH] xfs: return -ENOENT for unallocated inodes in xfs_imap_lookup

[Dave Chinner <dgc@kernel.org>]

On Wed, May 13, 2026 at 08:37:45AM +0200, Hans Holmberg wrote:
> Under heavy garbage collection pressure from RocksDB workloads,
> filesystem shutdowns can occur in xfs_zone_gc_iter_irec when
> xfs_iget() returns -EINVAL.
> 
> xfs_zone_gc_iter_irec expects -ENOENT when garbage collection races
> with file deletion,

xfs_iget() returns -ENOENT when a lookup races with an unlink on the
cache hot side. When the inode is not in cache, it cannot race with
file deletion.

If we miss the cache, it will go read the inode from disk and then
check the state of it before inserting it into the cache. If the
inode mode is zero on disk, then we raced with unlink and -ENOENT
will be returned.

IOWs, a plain xfs_iget() call will handle races with unlink...

> so that blocks belonging to deleted files can be
> skipped gracefully. Returning -EINVAL instead causes the GC code to
> treat this as a fatal error and forces a shutdown.

If it passes in XFS_IGET_UNTRUSTED to xfs_iget(), then it is saying
the inode number comes from an unknown source and that may be invalid.
Hence we do more rigorous and costly checks on the inode number
(like force a btree lookup) if it is not already validated and in
cache. If any of these validation checks fail we return EINVAL to
indicate it was an invalid inode number.

IOWs, xfs_iget(XFS_IGET_UNTRUSTED) callers need to handle -EINVAL,
because validity checking the inode number is what the caller -asked
it to do-.

If you are using inode number from a trusted source (i.e. internal
filesystem metadata like a directory data block or rmapbt) then you
don't need XFS_IGET_UNTRUSTED. The inode number is known to be good,
modulo races with unlink which xfs_iget() handles anyway...

-Dave.
-- 
Dave Chinner
dgc@kernel.org