From: Qiang Ma <maqianga@uniontech.com>
To: cem@kernel.org, djwong@kernel.org, hch@infradead.org
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Qiang Ma <maqianga@uniontech.com>,
stable@vger.kernel.org
Subject: [PATCH v2] xfs: clear zapped attr fork state when bmap repair finds no attr fork
Date: Thu, 16 Jul 2026 17:22:45 +0800 [thread overview]
Message-ID: <20260716092245.1847930-1-maqianga@uniontech.com> (raw)
xfstests xfs/377 can make xfs_scrub repeatedly check and repair the
attr block map after inode repair zaps an attr fork.
When inode repair zaps an attr fork, it records
XFS_SICK_INO_BMBTA_ZAPPED so that scrub/repair can revisit the attr fork
block map. If the fork has been reset to an empty state and removed,
BMBTA repair has no attr fork mappings to rebuild and can return success.
The post-repair scrub then runs with XREP_ALREADY_FIXED set, which means
xchk_file_looks_zapped() deliberately ignores the stale zapped health bit
and asks xchk_bmap() to check the current attr fork. For an absent attr
fork, xchk_bmap() returns -ENOENT. Returning that error prevents
xchk_bmap_attr() from marking XFS_SICK_INO_BMBTA_ZAPPED healthy, leaving
the zapped health state behind even though there are no attr fork mappings
left to check.
Treat -ENOENT during post-repair BMBTA revalidation as a clean result for
the zapped attr fork: clear XFS_SICK_INO_BMBTA_ZAPPED and return success.
Keep the existing -ENOENT behavior for ordinary scrubs of absent attr
forks.
Fixes: d9041681dd2f ("xfs: set inode sick state flags when we zap either ondisk fork")
Cc: <stable@vger.kernel.org> # v6.8
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Qiang Ma <maqianga@uniontech.com>
---
Changes since v1:
- Move the overly long repaired empty attr fork comment above the if.
- Add Cc stable and Reviewed-by tags.
fs/xfs/scrub/bmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/xfs/scrub/bmap.c b/fs/xfs/scrub/bmap.c
index 70028da1aacc7..401c278725d21 100644
--- a/fs/xfs/scrub/bmap.c
+++ b/fs/xfs/scrub/bmap.c
@@ -1170,6 +1170,11 @@ xchk_bmap_attr(
}
error = xchk_bmap(sc, XFS_ATTR_FORK);
+ /* A repaired, empty attr fork no longer has mappings to check. */
+ if (error == -ENOENT && (sc->flags & XREP_ALREADY_FIXED)) {
+ xchk_mark_healthy_if_clean(sc, XFS_SICK_INO_BMBTA_ZAPPED);
+ return 0;
+ }
if (error)
return error;
--
2.20.1
next reply other threads:[~2026-07-16 9:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 9:22 Qiang Ma [this message]
2026-07-16 9:24 ` [PATCH v2] xfs: clear zapped attr fork state when bmap repair finds no attr fork Christoph Hellwig
2026-07-21 10:44 ` Carlos Maiolino
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=20260716092245.1847930-1-maqianga@uniontech.com \
--to=maqianga@uniontech.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@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