public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuto Ohnuki <ytohnuki@amazon.com>
To: Carlos Maiolino <cem@kernel.org>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
	Dave Chinner <dgc@kernel.org>, <linux-xfs@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, Yuto Ohnuki <ytohnuki@amazon.com>
Subject: [PATCH v3 0/3] xfs: clean up directory data block header padding
Date: Sat, 11 Apr 2026 15:24:12 +0100	[thread overview]
Message-ID: <20260411142411.72194-5-ytohnuki@amazon.com> (raw)

The pad field in xfs_dir3_data_hdr exists for 64-bit alignment and 
should always be zero. Old kernels zeroed only the xfs_dir3_blk_hdr 
portion of the header during initialization and initialized the 
remaining header contents separately.

This series takes a broader approach as suggested by Dave Chinner:
zero the entire header region unconditionally, self-heal stale non-zero
padding during writes, and report remaining non-zero padding in scrub.

Patch 1 zeroes the entire directory data block header region in
xfs_dir3_data_init instead of just the xfs_dir3_blk_hdr.
Patch 2 zeroes the pad field in xfs_dir3_data_write_verify so that
existing directories self-heal when modified.
Patch 3 checks the pad field in scrub and adds xchk_fblock_set_preen.

Changes in v3:
- Zero the entire header region (geo->data_entry_offset bytes)
  unconditionally instead of changing the memset type to
  xfs_dir3_data_hdr.
- Remove the now-unnecessary bestfree manual zeroing loop.
- Zero pad in xfs_dir3_data_write_verify for runtime self-healing
  of old metadata.
- Drop unnecessary cpu_to_be32() on comparison to zero.
- Split into a 3-patch series for easier review.
- Link to v2: https://lore.kernel.org/all/20260408172749.99216-2-ytohnuki@amazon.com/#t

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

Yuto Ohnuki (3):
  xfs: zero entire directory data block header region at init
  xfs: zero directory data block padding on write verification
  xfs: check directory data block header padding in scrub

 fs/xfs/libxfs/xfs_dir2_data.c | 18 +++++++++++-------
 fs/xfs/scrub/common.c         | 11 +++++++++++
 fs/xfs/scrub/common.h         |  2 ++
 fs/xfs/scrub/dir.c            |  7 ++++++-
 4 files changed, 30 insertions(+), 8 deletions(-)

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




             reply	other threads:[~2026-04-11 14:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-11 14:24 Yuto Ohnuki [this message]
2026-04-11 14:24 ` [PATCH v3 1/3] xfs: zero entire directory data block header region at init Yuto Ohnuki
2026-04-11 14:24 ` [PATCH v3 2/3] xfs: zero directory data block padding on write verification Yuto Ohnuki
2026-04-11 14:24 ` [PATCH v3 3/3] xfs: check directory data block header padding in scrub Yuto Ohnuki

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=20260411142411.72194-5-ytohnuki@amazon.com \
    --to=ytohnuki@amazon.com \
    --cc=cem@kernel.org \
    --cc=dgc@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