From: sashiko-bot@kernel.org
To: "Yu Kuai" <yukuai@kernel.org>
Cc: yukuai@fygo.io, linux-raid@vger.kernel.org
Subject: Re: [PATCH v3 14/21] md/md-llbitmap: clamp state-machine walks to tracked bits
Date: Tue, 28 Jul 2026 09:13:13 +0000 [thread overview]
Message-ID: <20260728091314.162021F000E9@smtp.kernel.org> (raw)
In-Reply-To: <0510090c2be122814404150096768b180d0301e9.1785206690.git.yukuai@fygo.io>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] `llbitmap_cond_end_sync` prematurely clears the sync state for partially synced chunks, leading to skipped sectors and data corruption.
--
--- Patch [14]: [PATCH v3 14/21] md/md-llbitmap: clamp state-machine walks to tracked bits ---
commit d30fecfeaabb2957753288e01ac48b29a04d716a
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: clamp state-machine walks to tracked bits
This commit clamps the state-machine range to llbitmap->chunks to
prevent it from walking past the tracked bitmap when handling boundary
conditions.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 794ac0eaf4379..bb83d15247d23 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -1011,7 +1011,10 @@ static enum llbitmap_state llbitmap_state_machine(struct llbitmap *llbitmap,
> llbitmap_init_state(llbitmap);
> return BitNone;
> }
> -
> + if (start >= llbitmap->chunks)
> + return BitNone;
> + if (end >= llbitmap->chunks)
> + end = llbitmap->chunks - 1;
[Severity: Critical]
This is a pre-existing issue, but does llbitmap_cond_end_sync() prematurely
clear the sync state for partially synced chunks?
During array resync or initial build, the current resync position (sector)
typically advances by stripe size or resync sectors, which is smaller than
the bitmap chunk size. This means sector almost always falls in the middle of
a chunk.
When llbitmap_cond_end_sync() calls:
drivers/md/md-llbitmap.c:llbitmap_cond_end_sync() {
...
llbitmap_state_machine(llbitmap, 0, sector >> llbitmap->chunkshift,
BitmapActionEndsync);
...
}
it calculates the inclusive end bound for Endsync but fails to ensure only
fully completed chunks are processed, applying BitmapActionEndsync to the
partially completed chunk that sector resides in.
Because the state machine transitions partially-synced chunks to BitDirty or
BitCleanUnwritten, the next call to md_bitmap_start_sync() in the same chunk
will evaluate to BitNone and return false.
Will this cause the sync thread to skip the remaining sectors of that chunk
without resyncing them, leaving stale parity or unsynced mirrors on the disk?
> while (start <= end) {
> enum llbitmap_state c = llbitmap_read(llbitmap, start);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785206690.git.yukuai@fygo.io?part=14
next prev parent reply other threads:[~2026-07-28 9:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 8:49 [PATCH v3 00/21] md/md-llbitmap: support reshape for RAID10 and RAID5 Yu Kuai
2026-07-28 8:49 ` [PATCH v3 01/21] md/raid5: round bitmap stripes with sector division Yu Kuai
2026-07-28 9:03 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 02/21] md: add exact bitmap mapping and reshape hooks Yu Kuai
2026-07-28 8:49 ` [PATCH v3 03/21] md: skip bitmap accounting for empty write ranges Yu Kuai
2026-07-28 8:49 ` [PATCH v3 04/21] md: add helper to split bios at reshape offset Yu Kuai
2026-07-28 9:03 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 05/21] md/md-llbitmap: track bitmap sync_size explicitly Yu Kuai
2026-07-28 9:16 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 06/21] md/md-llbitmap: allocate page controls independently Yu Kuai
2026-07-28 9:06 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 07/21] md/md-llbitmap: grow the page cache in place for reshape Yu Kuai
2026-07-28 9:09 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 08/21] md/md-llbitmap: track target reshape geometry fields Yu Kuai
2026-07-28 9:12 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 09/21] md/md-llbitmap: finish reshape geometry Yu Kuai
2026-07-28 9:14 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 10/21] md/md-llbitmap: refuse reshape while llbitmap still needs sync Yu Kuai
2026-07-28 9:12 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 11/21] md/md-llbitmap: add reshape range mapping helpers Yu Kuai
2026-07-28 9:11 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 12/21] md/md-llbitmap: don't skip reshape ranges from bitmap state Yu Kuai
2026-07-28 8:49 ` [PATCH v3 13/21] md/md-llbitmap: remap checkpointed bits as reshape progresses Yu Kuai
2026-07-28 9:06 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 14/21] md/md-llbitmap: clamp state-machine walks to tracked bits Yu Kuai
2026-07-28 9:13 ` sashiko-bot [this message]
2026-07-28 8:49 ` [PATCH v3 15/21] md/raid10: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-07-28 9:15 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 16/21] md/raid10: wire llbitmap reshape lifecycle Yu Kuai
2026-07-28 9:22 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 17/21] md/raid10: split reshape bios before bitmap accounting Yu Kuai
2026-07-28 9:15 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 18/21] md/raid5: add exact old and new llbitmap mapping helpers Yu Kuai
2026-07-28 9:25 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 19/21] md/raid5: reject llbitmap reshape when md chunk shrinks Yu Kuai
2026-07-28 9:22 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 20/21] md/raid5: wire llbitmap reshape lifecycle Yu Kuai
2026-07-28 9:21 ` sashiko-bot
2026-07-28 8:49 ` [PATCH v3 21/21] md/raid5: split reshape bios before bitmap accounting Yu Kuai
2026-07-28 9:26 ` sashiko-bot
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=20260728091314.162021F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yukuai@fygo.io \
--cc=yukuai@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