Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Weiming Shi <bestswngs@gmail.com>
To: Carlos Maiolino <cem@kernel.org>, "Darrick J . Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	xmei5@asu.edu, Weiming Shi <bestswngs@gmail.com>
Subject: [PATCH v2 0/2] xfs: add a log item verifier pass to recovery
Date: Fri, 17 Jul 2026 12:24:06 -0700	[thread overview]
Message-ID: <20260717192408.109168-1-bestswngs@gmail.com> (raw)

v1 added the missing region and structure checks piecemeal in the pass2
inode decode. As Dave pointed out, that mixes validation into the decode
and replay code and is hard to audit. v2 reworks it into a verifier pass
run in the pass1 scan.

Patch 1 handles the generic part: an item not logging all the regions its
format declared is a log format property, not an inode concern, so
xlog_recover_commit_trans() rejects any such item for all item types. This
alone fixes the reported mount-time NULL deref.

Patch 2 adds a ->verify() method to xlog_recover_item_ops, called in pass1
for every item, with xlog_recover_inode_verify() as the first user, and
removes the log dinode checks it subsumes from the pass2 inode decode. The
checks that need the on-disk inode buffer (its magic, the LSN/di_flushiter
replay-ordering decisions, di_mode/di_format consistency, and the final
xfs_dinode_verify()) cannot move to pass1 and stay in pass2.

Scope: only the inode item is converted, and only its self-contained log
dinode structure. The btree-root fork record count is not yet bounded
(clamping xfs_bmbt_to_bmdr() and the rt converters is a separate fix), and
the other item types can grow their own verify() the same way.

Reproduced and regression-tested on a crafted dirty-log image under QEMU:
the crafted item is rejected in pass1 with the mount refused (EFSCORRUPTED)
instead of crashing (20/20 runs, no oops), and log recovery of a
filesystem populated with a range of inode types (regular files,
directories, symlinks, hardlinks, xattrs, device nodes, and a btree-format
data fork) is unaffected.

v2:
- Moved the "all declared regions logged" check into
  xlog_recover_commit_trans() as a generic check for all item types.
- Reworked the inode validation into a pass1 ->verify() hook on
  xlog_recover_item_ops, and removed the now-redundant log dinode checks
  (magic, forkoff) from xlog_recover_inode_commit_pass2().

Weiming Shi (2):
  xfs: reject log items with missing regions during recovery
  xfs: verify recovered inode log items in pass1

 fs/xfs/libxfs/xfs_log_recover.h |  3 ++
 fs/xfs/xfs_inode_item_recover.c | 87 +++++++++++++++++++++++++++------
 fs/xfs/xfs_log_recover.c        | 16 ++++++
 3 files changed, 90 insertions(+), 16 deletions(-)

-- 
2.43.0


             reply	other threads:[~2026-07-17 19:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 19:24 Weiming Shi [this message]
2026-07-17 19:24 ` [PATCH v2 1/2] xfs: reject log items with missing regions during recovery Weiming Shi
2026-07-17 22:59   ` Dave Chinner
2026-07-17 19:24 ` [PATCH v2 2/2] xfs: verify recovered inode log items in pass1 Weiming Shi

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=20260717192408.109168-1-bestswngs@gmail.com \
    --to=bestswngs@gmail.com \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=xmei5@asu.edu \
    /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