From: Yuto Ohnuki <ytohnuki@amazon.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
<linux-xfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Yuto Ohnuki <ytohnuki@amazon.com>
Subject: [PATCH v2] xfs: check directory data block header padding in scrub
Date: Wed, 8 Apr 2026 18:27:50 +0100 [thread overview]
Message-ID: <20260408172749.99216-2-ytohnuki@amazon.com> (raw)
The pad field in xfs_dir3_data_hdr exists for 64-bit alignment and
should always be zero.
First, fix xfs_dir3_data_init to zero the full xfs_dir3_data_hdr instead
of just xfs_dir3_blk_hdr so that the pad field is covered by the memset.
Then, add the missing scrub check for the pad field in directory data
block headers. Since old kernels may have written non-zero padding
without issue, flag this as an optimization opportunity (preen) rather
than corruption. Add xchk_fblock_set_preen helper for this purpose.
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
---
Changes in v2:
- Fix xfs_dir3_data_init to zero the full xfs_dir3_data_hdr instead of
just xfs_dir3_blk_hdr so that the pad field is covered by the memset.
- Use xchk_fblock_set_preen instead of xchk_fblock_set_corrupt since
old kernels may have written non-zero padding without issues.
- Add xchk_fblock_set_preen helper function.
- Link to v1: https://lore.kernel.org/all/20260404125032.37693-2-ytohnuki@amazon.com/#t
---
fs/xfs/libxfs/xfs_dir2_data.c | 10 +++++-----
fs/xfs/scrub/common.c | 11 +++++++++++
fs/xfs/scrub/common.h | 2 ++
fs/xfs/scrub/dir.c | 7 ++++++-
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_dir2_data.c b/fs/xfs/libxfs/xfs_dir2_data.c
index 80ba94f51e5c..037f9449835d 100644
--- a/fs/xfs/libxfs/xfs_dir2_data.c
+++ b/fs/xfs/libxfs/xfs_dir2_data.c
@@ -745,13 +745,13 @@ xfs_dir3_data_init(
*/
hdr = bp->b_addr;
if (xfs_has_crc(mp)) {
- struct xfs_dir3_blk_hdr *hdr3 = bp->b_addr;
+ struct xfs_dir3_data_hdr *hdr3 = bp->b_addr;
memset(hdr3, 0, sizeof(*hdr3));
- hdr3->magic = cpu_to_be32(XFS_DIR3_DATA_MAGIC);
- hdr3->blkno = cpu_to_be64(xfs_buf_daddr(bp));
- hdr3->owner = cpu_to_be64(args->owner);
- uuid_copy(&hdr3->uuid, &mp->m_sb.sb_meta_uuid);
+ hdr3->hdr.magic = cpu_to_be32(XFS_DIR3_DATA_MAGIC);
+ hdr3->hdr.blkno = cpu_to_be64(xfs_buf_daddr(bp));
+ hdr3->hdr.owner = cpu_to_be64(args->owner);
+ uuid_copy(&hdr3->hdr.uuid, &mp->m_sb.sb_meta_uuid);
} else
hdr->magic = cpu_to_be32(XFS_DIR2_DATA_MAGIC);
diff --git a/fs/xfs/scrub/common.c b/fs/xfs/scrub/common.c
index 20e63069088b..3d40cb0b2496 100644
--- a/fs/xfs/scrub/common.c
+++ b/fs/xfs/scrub/common.c
@@ -251,6 +251,17 @@ xchk_ino_set_preen(
trace_xchk_ino_preen(sc, ino, __return_address);
}
+/* Record a block indexed by a file fork that could be optimized. */
+void
+xchk_fblock_set_preen(
+ struct xfs_scrub *sc,
+ int whichfork,
+ xfs_fileoff_t offset)
+{
+ sc->sm->sm_flags |= XFS_SCRUB_OFLAG_PREEN;
+ trace_xchk_fblock_preen(sc, whichfork, offset, __return_address);
+}
+
/* Record something being wrong with the filesystem primary superblock. */
void
xchk_set_corrupt(
diff --git a/fs/xfs/scrub/common.h b/fs/xfs/scrub/common.h
index f2ecc68538f0..b494d747c008 100644
--- a/fs/xfs/scrub/common.h
+++ b/fs/xfs/scrub/common.h
@@ -25,6 +25,8 @@ bool xchk_fblock_xref_process_error(struct xfs_scrub *sc,
void xchk_block_set_preen(struct xfs_scrub *sc,
struct xfs_buf *bp);
void xchk_ino_set_preen(struct xfs_scrub *sc, xfs_ino_t ino);
+void xchk_fblock_set_preen(struct xfs_scrub *sc,
+ int whichfork, xfs_fileoff_t offset);
void xchk_set_corrupt(struct xfs_scrub *sc);
void xchk_block_set_corrupt(struct xfs_scrub *sc,
diff --git a/fs/xfs/scrub/dir.c b/fs/xfs/scrub/dir.c
index e09724cd3725..0a1ec94961ed 100644
--- a/fs/xfs/scrub/dir.c
+++ b/fs/xfs/scrub/dir.c
@@ -492,7 +492,12 @@ xchk_directory_data_bestfree(
goto out;
xchk_buffer_recheck(sc, bp);
- /* XXX: Check xfs_dir3_data_hdr.pad is zero once we start setting it. */
+ if (xfs_has_crc(sc->mp)) {
+ struct xfs_dir3_data_hdr *hdr3 = bp->b_addr;
+
+ if (hdr3->pad != cpu_to_be32(0))
+ xchk_fblock_set_preen(sc, XFS_DATA_FORK, lblk);
+ }
if (sc->sm->sm_flags & XFS_SCRUB_OFLAG_CORRUPT)
goto out_buf;
--
2.50.1
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
next reply other threads:[~2026-04-08 17:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 17:27 Yuto Ohnuki [this message]
2026-04-08 21:38 ` [PATCH v2] xfs: check directory data block header padding in scrub 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=20260408172749.99216-2-ytohnuki@amazon.com \
--to=ytohnuki@amazon.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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