Re: [PATCH v2] xfs: bound logged region access in inode buffer recovery

[Dave Chinner <dgc@kernel.org>]

On Tue, Sep 08, 2026 at 03:48:03PM +0800, Hongling Zeng wrote:
> 在 2026年09月08日 14:33, Dave Chinner 写道:
> > Don't take the design doc as being complete or correct - it's a
> > working document and really only serves as the initial high level
> > plan I fleshed out.
> > 
> > Indeed, I implemented a chunk of it yesterday afternoon (i.e.
> > before I saw your patch this morning) and my findings change quite a
> > bit of the generic infrastructure to make it handle the transaction
> > header without having to special case it. So from that perspective,
> > it's already out of date...
> > 
> > I'll post what I have in the series later this afternoon so you can
> > get up to speed.

Ok, I just posted my current WIP to the log-verification-1 branch in
my kernel.org repo
(https://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git)

This is completely untested, I've only made sure it compiles. Don't
expect it to work. If you do start adding to it, build on top of it
and point me to the git repo where all your new work can be found.

What I've implemented so far is the refactoring necessary to
implement generic handling of log item verification and decoding,
converted the special case transhdr decoding to use the generic
infrastructure, and implemented fairly complete ophdr validation,
including validation of the log unmount record (which isn't
validated in any way right now).

Design has changed to use methods for item specific region count
checking, as well as adding a completion method that allows item
types to consume the item rather than queuing it for later recovery
(both needed for the transhdr conversion). Implementation has been
refined to avoid decoding ophdrs until sufficient validation has
been performed to guarantee the buffer pointer is sane and is long
enough to contain a full ophdr, and then it valdates the rest of the
ophdr before passing it to the processing code.

The next steps are to start implementing the per-item type
validation functions.

I also noticed that the head/tail search code that reads log
record headers doesn't really do much validation on the log record
headers. We probably need to address that, too, so we can detect
corrupted headers during the head/tail search and avoid finding
incorrect head/tail records as a result.

> Once your series is posted I'll start with review and the
> recoveryloop / logprint-based testing, then take the per-type
> validate_region() / validate_item() implementations on top of your
> iterator.

I think it's probably better that you first read the code yourself
and develop an understanding of what needs to be done without the
aid of an LLM. See if you can find bugs in what I've already done
-without- an LLM - you will learn the code at the same time, and
then be in a much better place to guide an LLM through later stages
of development.

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org