Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Hans Holmberg <hans.holmberg@wdc.com>
To: Carlos Maiolino <cem@kernel.org>, "Darrick J . Wong" <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@lst.de>,
	Damien Le Moal <dlemoal@kernel.org>,
	linux-xfs@vger.kernel.org, Hans Holmberg <hans.holmberg@wdc.com>
Subject: [PATCH] xfs: return -ENOENT for unallocated inodes in xfs_imap_lookup
Date: Wed, 13 May 2026 08:37:45 +0200	[thread overview]
Message-ID: <20260513063745.8067-1-hans.holmberg@wdc.com> (raw)

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

Fix this by returning -ENOENT from xfs_imap_lookup for untrusted inodes
when the inode has been deleted, allowing zone GC to safely ignore stale
mappings.

Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
---

We could also fix this up in xfs_zone_gc_iter_irec, and handle -EINVAL
as a non-fatal error, but returning -ENOENT from xfs_imap_lookup seems
like the more right thing to do.

The check "that the returned record contains the required inode" in
xfs_imap_lookup also returns -EINVAL and might be worth switching
over to -ENOENT but I'm leaving that as is I did not hit that case
in my testing.

 fs/xfs/libxfs/xfs_ialloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c
index dcef06ec0a02..702e1e853e45 100644
--- a/fs/xfs/libxfs/xfs_ialloc.c
+++ b/fs/xfs/libxfs/xfs_ialloc.c
@@ -2442,7 +2442,7 @@ xfs_imap_lookup(
 	/* for untrusted inodes check it is allocated first */
 	if ((flags & XFS_IGET_UNTRUSTED) &&
 	    (rec.ir_free & XFS_INOBT_MASK(agino - rec.ir_startino)))
-		return -EINVAL;
+		return -ENOENT;
 
 	*chunk_agbno = XFS_AGINO_TO_AGBNO(mp, rec.ir_startino);
 	*offset_agbno = agbno - *chunk_agbno;
-- 
2.34.1


             reply	other threads:[~2026-05-13  6:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  6:37 Hans Holmberg [this message]
2026-05-13  6:57 ` [PATCH] xfs: return -ENOENT for unallocated inodes in xfs_imap_lookup Christoph Hellwig
2026-05-13  7:31 ` Carlos Maiolino
2026-05-13 13:43 ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260513063745.8067-1-hans.holmberg@wdc.com \
    --to=hans.holmberg@wdc.com \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox