From: Hongling Zeng <zhongling0719@126.com>
To: Dave Chinner <dgc@kernel.org>
Cc: Hongling Zeng <zenghongling@kylinos.cn>,
cem@kernel.org, darrick.wong@oracle.com,
chandanrlinux@gmail.com, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2] xfs: bound logged region access in inode buffer recovery
Date: Wed, 09 Sep 2026 15:40:17 +0800 [thread overview]
Message-ID: <6AA10D61.6030403@126.com> (raw)
In-Reply-To: <aqCTfSqqywJ5qKcY@dread>
在 2026年09月09日 07:00, Dave Chinner 写道:
> 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.
>
Thanks for posting the WIP series.
I’ll work from the log-verification-1 branch and first study the generic
iterator and item handling rather than extending the old special cases.
I’ll pay particular attention to arbitrary continuation fragments,
zero-length first fragments, transaction-header completion, and cleanup
on malformed input.
I’ll review the existing code for bugs before adding the per-item
validation functions, and will point you to my repository once I have
work based on the branch.
Thanks,
Hongling
next prev parent reply other threads:[~2026-09-09 7:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 8:04 [PATCH v2] xfs: bound logged region access in inode buffer recovery Hongling Zeng
2026-09-07 21:36 ` Dave Chinner
2026-09-08 2:17 ` Hongling Zeng
2026-09-08 6:33 ` Dave Chinner
2026-09-08 7:48 ` Hongling Zeng
2026-09-08 23:00 ` Dave Chinner
2026-09-09 7:40 ` Hongling Zeng [this message]
2026-09-12 7:02 ` Hongling Zeng
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=6AA10D61.6030403@126.com \
--to=zhongling0719@126.com \
--cc=cem@kernel.org \
--cc=chandanrlinux@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=dgc@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=zenghongling@kylinos.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.