* Re: [PATCH v2 18/20] md/raid5: reject llbitmap reshape when md chunk shrinks
From: sashiko-bot @ 2026-06-24 7:24 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <9b06d3a655f709b35ab10995a872b30d2026f7c3.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The validation in `check_reshape` fails to reject reshapes that decrease the number of data disks (`mddev->delta_disks < 0`) for llbitmap, leaving an identical bitmap coverage truncation vulnerability to the one the patch attempts to fix.
Pre-existing issues:
- [High] Writing 0 or a very small/overflowing value to the `chunk_size` sysfs attribute bypasses chunk size validation, leading to a divide-by-zero kernel panic during reshape.
- [High] Pre-existing memory leak of `stripe_head` pages in `resize_stripes()` if array reshape initialization fails.
--
commit cd96767f06f730181f5e43d1d52815ff0535ad82
Author: Yu Kuai <yukuai@fygo.io>
md/raid5: reject llbitmap reshape when md chunk shrinks
llbitmap reshape keeps one live bitmap and cannot safely make an
existing bitmap bit cover a smaller data range.
The llbitmap chunksize itself will not shrink when mddev->chunk_sectors
stays the same or grows. However, shrinking mddev->chunk_sectors shrinks
sectors_per_chunk used by raid5_bitmap_sector_map(). That can shrink the
effective data range covered by each bit across the old and new RAID5
geometry. Reject that reshape while llbitmap is active.
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 1613a42cc25dc..9de648f75dd04 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -8506,6 +8506,9 @@ static int check_reshape(struct mddev *mddev)
> if (!check_stripe_cache(mddev))
> return -ENOSPC;
>
> + if (mddev->bitmap_id == ID_LLBITMAP &&
> + mddev->new_chunk_sectors < mddev->chunk_sectors)
> + return -EOPNOTSUPP;
[Severity: High]
Does this validation fully address the logical coverage truncation?
The commit message correctly notes that shrinking mddev->chunk_sectors shrinks
sectors_per_chunk, which is unsafe for llbitmap because it shrinks the
effective data range covered by each bit.
However, sectors_per_chunk is also reduced if mddev->delta_disks < 0:
sectors_per_chunk = chunk_sectors * (raid_disks - max_degraded);
Since the validation here only checks if the new chunk sectors are smaller,
a reshape that reduces the number of data disks could bypass this check,
resulting in the exact same logical coverage truncation vulnerability.
Could this be updated to also check mddev->delta_disks < 0, or compute the
product to verify sectors_per_chunk does not shrink?
> if (mddev->new_chunk_sectors > mddev->chunk_sectors ||
> mddev->delta_disks > 0)
[Severity: High]
This is a pre-existing issue, but writing 0 or a very small value to the
chunk_size sysfs attribute appears to bypass chunk size validation entirely,
leading to a divide-by-zero panic during reshape.
In drivers/md/md.c:chunk_size_store(), user input is right-shifted by 9
to compute mddev->new_chunk_sectors. If the user writes 0, it becomes 0.
When raid5_check_reshape() is called:
drivers/md/raid5.c:raid5_check_reshape() {
...
if (new_chunk > 0) {
if (!is_power_of_2(new_chunk))
return -EINVAL;
...
}
Because the checks are inside if (new_chunk > 0), a value of 0 skips the
sanity bounds. check_reshape() then accepts it.
Later, in raid5_compute_sector(), this chunk size causes a kernel panic:
drivers/md/raid5.c:raid5_compute_sector() {
...
chunk_offset = sector_div(r_sector, sectors_per_chunk);
...
}
Should chunk_size_store() or raid5_check_reshape() explicitly prevent a
chunk size of 0?
> if (resize_chunks(conf,
> conf->previous_raid_disks
> + max(0, mddev->delta_disks),
> max(mddev->new_chunk_sectors,
> mddev->chunk_sectors)
> ) < 0)
> return -ENOMEM;
>
> if (conf->previous_raid_disks + mddev->delta_disks <= conf->pool_size)
> return 0; /* never bother to shrink */
> return resize_stripes(conf, (conf->previous_raid_disks
> + mddev->delta_disks));
> }
[Severity: High]
This isn't a bug introduced by this patch, but is it possible for
resize_stripes() to leak the stripe_head pages if the array reshape
initialization fails?
If the array reshape fails under memory pressure during step 3 of
resize_stripes() (for example, the ndisks allocation fails), the function
structurally proceeds to step 4 without aborting:
drivers/md/raid5.c:resize_stripes() {
...
for (i=conf->raid_disks; i < newsize; i++)
if (nsh->dev[i].page == NULL) {
struct page *p = alloc_page(GFP_NOIO);
nsh->dev[i].page = p;
...
}
It loops up to newsize and allocates physical pages for the expanded stripe
slots. At the end of the function, because err is set, it skips updating
conf->pool_size:
drivers/md/raid5.c:resize_stripes() {
...
if (!err)
conf->pool_size = newsize;
...
}
Since conf->pool_size is unchanged, any future teardown via shrink_buffers()
will intentionally ignore the newly allocated pages at indices >= pool_size.
When free_stripe() subsequently destroys the slab object without freeing these
pages, they appear to be permanently leaked.
Is there a mechanism that cleans up these orphaned pages if conf->pool_size
is not updated?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=18
^ permalink raw reply
* Re: [PATCH 4/7] md/raid10: raid10_write_request() drops the barrier before calling
From: yu kuai @ 2026-06-24 7:23 UTC (permalink / raw)
To: Abd-Alrhman Masalkhi, song, magiclinan, xiao, axboe, john.g.garry,
martin.petersen, yukuai
Cc: linux-raid, linux-kernel
In-Reply-To: <20260623072456.333437-5-abd.masalkhi@gmail.com>
Hi,
在 2026/6/23 15:24, Abd-Alrhman Masalkhi 写道:
> bio_submit_split_bioset() and reacquires it afterwards. This is
> unnecessary because bio_submit_split_bioset() does not require
> releasing the barrier protection.
Why is this safe?
It's possible plug is not enabled in this context, and the allocated new
aplit bio will be submitted and enter wait_barrier() again. wait_barrier()
is not supposed to be called recursively. Otherwise deadlock can happend:
t1: sync_thread grab barrier and waiting for nr_pending to be 0 from raise_barrier()
t2: wait_barrier() first inc nr_pending, then recursive wait_barrier() waiting
for barrier to be released.
>
> Remove the redundant allow_barrier()/wait_barrier() pair around
> bio_submit_split_bioset().
>
> Signed-off-by: Abd-Alrhman Masalkhi <abd.masalkhi@gmail.com>
> ---
> drivers/md/raid10.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 840f0446c231..4bc1d5553ec7 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -1493,10 +1493,8 @@ static bool raid10_write_request(struct mddev *mddev, struct bio *bio,
> if (atomic)
> goto err_handle;
>
> - allow_barrier(conf);
> bio = bio_submit_split_bioset(bio, r10_bio->sectors,
> &conf->bio_split);
> - wait_barrier(conf, false);
> if (!bio) {
> set_bit(R10BIO_Returned, &r10_bio->state);
> goto err_handle;
--
Thanks,
Kuai
^ permalink raw reply
* Re: [PATCH v2 15/20] md/raid10: wire llbitmap reshape lifecycle
From: sashiko-bot @ 2026-06-24 7:22 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <54625332edcdb5f009fb0920220ea12aa696f408.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] raid10_start_reshape skips initializing llbitmap's reshape geometry, causing bitmap corruption during and after reshape.
- [Low] Hardcoded check for `ID_LLBITMAP` in `raid10_finish_reshape` breaks the polymorphism of `mddev->bitmap_ops`.
--
commit 84732a3d166ed5b144ce82fb596703bb8b35f73c
Author: Yu Kuai <yukuai@fygo.io>
md/raid10: wire llbitmap reshape lifecycle
Prepare llbitmap before RAID10 starts growing, checkpoint the bitmap
before advancing reshape_position, finish the llbitmap geometry update
when reshape completes, and export the old and new tracked sizes.
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index 1242b8d3bb6bd..e50e4adee389f 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -4394,6 +4394,12 @@ static int raid10_start_reshape(struct mddev *mddev)
>
> if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
> return -EBUSY;
> + if (md_bitmap_enabled(mddev, false) &&
> + mddev->bitmap_ops->reshape_can_start) {
> + ret = mddev->bitmap_ops->reshape_can_start(mddev);
> + if (ret)
> + return ret;
> + }
[Severity: High]
Does this fully wire up the llbitmap reshape lifecycle?
Further down in raid10_start_reshape(), the call to mddev->bitmap_ops->resize()
is gated by `if (mddev->delta_disks && mddev->bitmap)`.
If a reshape is started that only grows the chunk size (where
mddev->delta_disks == 0), won't this skip initializing the llbitmap's reshape
geometry?
If resize() is bypassed, llbitmap->reshape_chunksize would remain at the old
chunk size, causing llbitmap_encode_range() for the new layout to map IOs
using the old chunk size. Could this set bits for incorrect regions, leading
to dirty data not being tracked properly and silent data corruption upon
array recovery?
[ ... ]
> @@ -5039,10 +5062,15 @@ static void end_reshape_request(struct r10bio *r10_bio)
> static void raid10_finish_reshape(struct mddev *mddev)
> {
> struct r10conf *conf = mddev->private;
> + bool llbitmap = mddev->bitmap_id == ID_LLBITMAP &&
> + md_bitmap_enabled(mddev, false);
>
> if (test_bit(MD_RECOVERY_INTR, &mddev->recovery))
> return;
>
> + if (llbitmap && mddev->bitmap_ops->reshape_finish)
> + mddev->bitmap_ops->reshape_finish(mddev);
[Severity: Low]
Is this hardcoded check for ID_LLBITMAP necessary?
By explicitly checking mddev->bitmap_id, this seems to defeat the polymorphism
of mddev->bitmap_ops. If another bitmap implementation introduces
reshape_finish(), wouldn't it be silently ignored?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=15
^ permalink raw reply
* Re: [PATCH v2 16/20] md/raid10: split reshape bios before bitmap accounting
From: sashiko-bot @ 2026-06-24 7:20 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <afeb48e05a8925b52e9def6bab1b0ca1e87c4aa0.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `md_write_end()` on `mddev_bio_split_at_reshape_offset()` failure path causes `writes_pending` leak.
- [Medium] Lockless read of `mddev->reshape_position` can result in a torn read on 32-bit architectures, leading to incorrect bio splitting.
--
commit 2a6f82a757276f6bbae0c22cb819c9c6d6b3e4b0
Author: Yu Kuai <yukuai@fygo.io>
md/raid10: split reshape bios before bitmap accounting
Use the shared mddev_bio_split_at_reshape_offset() helper so RAID10
submits only one-side bios to llbitmap during reshape.
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -1911,6 +1911,12 @@ static bool raid10_make_request(struct mddev *mddev, struct bio *bio)
> sectors = chunk_sects -
> (bio->bi_iter.bi_sector &
> (chunk_sects - 1));
> +
> + bio = mddev_bio_split_at_reshape_offset(mddev, bio, §ors,
> + &conf->bio_split);
[Severity: Medium]
Can the lockless read of mddev->reshape_position inside this helper
result in a torn read on 32-bit architectures?
In mddev_bio_split_at_reshape_offset(), mddev->reshape_position (a 64-bit
sector_t) is read without READ_ONCE() or a seqcount:
drivers/md/md.c:mddev_bio_split_at_reshape_offset() {
...
boundary = mddev->reshape_position;
...
}
On 32-bit systems, could racing with the reshape thread's update (for
example, at the 2TB boundary) tear the 64-bit load and yield a garbage
sector value?
If so, this might cause bio_split to slice the bio at an unaligned offset,
leading to IO errors when the underlying block device rejects it.
> + if (!bio)
> + return true;
[Severity: High]
Does this early return bypass the md_write_end() cleanup required to
balance the earlier md_write_start() for write requests?
If mddev_bio_split_at_reshape_offset() fails and returns NULL, it appears
the writes_pending percpu reference is leaked.
Will this prevent the array from reaching the clean safemode state, causing
it to perpetually appear dirty and trigger a full resync on the next
assembly?
> +
> if (!__make_request(mddev, bio, sectors))
> md_write_end(mddev);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=16
^ permalink raw reply
* Re: [PATCH v2 19/20] md/raid5: wire llbitmap reshape lifecycle
From: sashiko-bot @ 2026-06-24 7:20 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <55686793056df8053d1797d22c18fce8df7eebe8.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Checkpointing the translated llbitmap to disk before the MD superblock is updated creates a crash window that leads to silent data corruption on restart.
- [Critical] The llbitmap page control array (`llbitmap->pctl`) can be accessed after being freed during RAID5 reshape initialization because the bitmap resize happens before the array is quiesced.
--
commit 18675e43f792016c6cde2f177af7a007c667120d
Author: Yu Kuai <yukuai@fygo.io>
md/raid5: wire llbitmap reshape lifecycle
Prepare llbitmap before RAID5 reshape starts, checkpoint the bitmap
before advancing reshape_position, and finish the llbitmap geometry
update when reshape completes.
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 9de648f75dd04..ac7ea483502fd 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
[ ... ]
> @@ -6430,6 +6430,13 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
> || test_bit(MD_RECOVERY_INTR, &mddev->recovery));
> if (atomic_read(&conf->reshape_stripes) != 0)
> return 0;
> + if (md_bitmap_enabled(mddev, false) &&
> + mddev->bitmap_ops->reshape_mark &&
> + conf->reshape_safe != conf->reshape_progress) {
> + mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
> + conf->reshape_progress);
> + mddev->bitmap_ops->unplug(mddev, true);
> + }
[Severity: Critical]
Does checkpointing the translated llbitmap to disk before the MD superblock
is updated create a crash window that leads to silent data corruption on
restart?
During RAID5 reshape, the code translates the bitmap to the new layout via
reshape_mark() and flushes it to disk before asynchronously waking the MD
thread to update the superblock.
If the system crashes after the bitmap flush but before the superblock write
completes, the on-disk metadata will still point to the old reshape position
(reshape_safe), while the on-disk bitmap for the region
[reshape_safe, reshape_progress] will be stored in the new layout.
On reboot, the array will resume the reshape from reshape_safe and
misinterpret the newly mapped bitmap bits as if they were in the old layout.
If the array is degraded during this restart, it might incorrectly assume the
parity for these sectors is in-sync and reconstruct missing data using
corrupted parity.
> mddev->reshape_position = conf->reshape_progress;
> mddev->curr_resync_completed = sector_nr;
> if (!mddev->reshape_backwards)
[ ... ]
> @@ -8571,6 +8585,12 @@ static int raid5_start_reshape(struct mddev *mddev)
> mdname(mddev));
> return -EINVAL;
> }
> + if (md_bitmap_enabled(mddev, false) &&
> + mddev->bitmap_id == ID_LLBITMAP) {
> + i = mddev->bitmap_ops->resize(mddev, mddev->dev_sectors, 0);
> + if (i)
> + return i;
> + }
[Severity: Critical]
Can this resize operation trigger a use-after-free regression since it
occurs before raid5_quiesce() stops concurrent I/O?
In raid5_start_reshape(), mddev->bitmap_ops->resize() is called to prepare
the bitmap for the new geometry before raid5_quiesce() is invoked. This means
the array is not suspended, and concurrent I/O is actively being handled.
If the resize operation calls llbitmap_expand_pages() and frees the old
pctl array via kfree() without RCU synchronization, concurrent fast-path I/O
threads executing llbitmap_start_write() could locklessly dereference the
freed pointer array in llbitmap_raise_barrier().
>
> atomic_set(&conf->reshape_stripes, 0);
> spin_lock_irq(&conf->device_lock);
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=19
^ permalink raw reply
* Re: [PATCH v2 17/20] md/raid5: add exact old and new llbitmap mapping helpers
From: sashiko-bot @ 2026-06-24 7:16 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <7f4f61a0c06d01b38b0a175ce5df9afe6450d09e.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] raid5_bitmap_array_sectors() incorrectly returns the new, smaller array size for the previous layout during a shrink reshape, leading to truncated bitmap tracking.
Pre-existing issues:
- [High] Invalid use of round_down() and round_up() with a non-power-of-2 sectors_per_chunk multiplier, causing corrupt bitmap mappings.
- [High] Bounding box calculation for mapping ranges between old and new layouts can overflow `unsigned long` on 32-bit systems, truncating dirty regions.
- [High] raid5_bitmap_sector_map() accesses reshape geometry parameters without holding the required sequence lock.
--
commit 7f0559d3994c9371245bbc6a23cf3ce1e8d48872
Author: Yu Kuai <yukuai@fygo.io>
md/raid5: add exact old and new llbitmap mapping helpers
Teach RAID5 to export exact old and new llbitmap mappings and the
corresponding sync and array sizes for reshape-aware bitmap users.
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 0c5c9fb0606ee..1613a42cc25dc 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
[ ... ]
> @@ -5942,25 +5942,43 @@ static enum reshape_loc get_reshape_loc(struct mddev *mddev,
[ ... ]
> -static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
> - unsigned long *sectors)
> +static void raid5_bitmap_sector_map(struct mddev *mddev, sector_t *offset,
> + unsigned long *sectors,
> + bool previous)
> {
> struct r5conf *conf = mddev->private;
> sector_t start = *offset;
> sector_t end = start + *sectors;
> - sector_t prev_start = start;
> - sector_t prev_end = end;
> int sectors_per_chunk;
> - enum reshape_loc loc;
> int dd_idx;
>
> - sectors_per_chunk = conf->chunk_sectors *
> - (conf->raid_disks - conf->max_degraded);
> + if (previous)
> + sectors_per_chunk = conf->prev_chunk_sectors *
> + (conf->previous_raid_disks - conf->max_degraded);
> + else
> + sectors_per_chunk = conf->chunk_sectors *
> + (conf->raid_disks - conf->max_degraded);
[Severity: High]
This is a pre-existing issue, but does raid5_bitmap_sector_map() access
these reshape geometry parameters safely?
During a concurrent reshape operation (e.g., raid5_start_reshape()), these
configuration fields can be updated in-place. Without being protected by
read_seqcount_begin(&conf->gen_lock), could a concurrent I/O observe torn
state or a mismatch between chunk size and raid disks, leading to an
incorrect bitmap mapping?
> start = round_down(start, sectors_per_chunk);
> end = round_up(end, sectors_per_chunk);
[Severity: High]
This is a pre-existing issue, but do round_down() and round_up() work correctly
here when sectors_per_chunk is not a power of 2?
The round_down() and round_up() macros perform a bitwise masking operation
which strictly requires the multiplier to be a power of 2. Because the
number of data disks (raid_disks - max_degraded) is often not a power of 2
(for example, 3 data disks in a 4-disk RAID5), sectors_per_chunk is frequently
not a power of 2.
Will this bitwise mask silently corrupt the logical offsets instead of rounding
to stripe boundaries, leading to incorrect physical regions being tracked in
the bitmap?
> - start = raid5_compute_sector(conf, start, 0, &dd_idx, NULL);
> - end = raid5_compute_sector(conf, end, 0, &dd_idx, NULL);
> + start = raid5_compute_sector(conf, start, previous, &dd_idx, NULL);
> + end = raid5_compute_sector(conf, end, previous, &dd_idx, NULL);
> + *offset = start;
> + *sectors = end - start;
> +}
> +
> +static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
> + unsigned long *sectors)
> +{
> + struct r5conf *conf = mddev->private;
> + sector_t start = *offset;
> + sector_t end = start + *sectors;
> + sector_t prev_start = start;
> + unsigned long prev_sectors = end - start;
> + enum reshape_loc loc;
> +
> + raid5_bitmap_sector_map(mddev, &start, sectors, false);
> + end = start + *sectors;
[ ... ]
> @@ -5987,7 +5998,7 @@ static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
> * we set bits for both.
> */
> *offset = min(start, prev_start);
> - *sectors = max(end, prev_end) - *offset;
> + *sectors = max(end, prev_start + prev_sectors) - *offset;
[Severity: High]
This isn't a bug introduced by this patch, but can this bounding box
calculation overflow on 32-bit systems?
When calculating the bounding box spanning the old and new physical layout
mappings for an I/O ahead of a reshape, the physical sector offsets diverge
linearly due to differing data disk counts.
For large arrays (e.g., >40TB), the gap between the mapped sectors can
exceed 2TB (4,294,967,295 sectors). Because *sectors is a pointer to
unsigned long (which is 32-bit on 32-bit architectures), could this
subtraction silently overflow, truncating the dirty region and potentially
missing necessary bits?
> }
>
> static enum stripe_result make_stripe_request(struct mddev *mddev,
[ ... ]
> @@ -9049,6 +9060,20 @@ static void raid5_prepare_suspend(struct mddev *mddev)
> wake_up(&conf->wait_for_reshape);
> }
>
> +static sector_t raid5_bitmap_sync_size(struct mddev *mddev, bool previous)
> +{
> + return mddev->dev_sectors;
> +}
> +
> +static sector_t raid5_bitmap_array_sectors(struct mddev *mddev, bool previous)
> +{
> + struct r5conf *conf = mddev->private;
> +
> + if (previous)
> + return raid5_size(mddev, 0, 0);
[Severity: High]
Does passing 0 for raid_disks in raid5_size() incorrectly truncate the array
size for the previous layout?
During an array shrink reshape (e.g., from 5 disks to 4), passing 0 forces
raid5_size() to use the minimum disk count between the old and new layouts.
This would return the new, smaller array size instead of the exact previous
layout's size.
Since reshape-aware bitmap users rely on this limit to clip logical I/O
offsets, could I/Os mapping to the old unreshaped region beyond the new
limit be erroneously discarded, leading to dropped dirty bits?
> + return raid5_size(mddev, mddev->dev_sectors, conf->raid_disks);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=17
^ permalink raw reply
* Re: [PATCH v2 10/20] md/md-llbitmap: add reshape range mapping helpers
From: sashiko-bot @ 2026-06-24 7:08 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <8a47becf3100a3998e003afcdabce6c17c149194.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] TOCTOU race on mddev->reshape_position causes bios to be mapped to the wrong geometry.
- [High] The resync threads use raw array sectors and blindly compute the bitmap bit index using the old geometry's chunkshift, completely ignoring reshape_chunksize for sectors residing in the new geometry.
--
commit a481d24ff8d12695efeabb7f320e930174126333
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: add reshape range mapping helpers
Teach llbitmap to choose old versus new geometry during reshape and to
encode exact bitmap ranges for the active geometry.
This is the mapping groundwork for checkpoint remapping.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 11fede1fc79fd..d27993cfb13da 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> @@ -1376,11 +1433,32 @@ static void llbitmap_destroy(struct mddev *mddev)
> mutex_unlock(&mddev->bitmap_info.mutex);
> }
>
> +static bool llbitmap_map_previous(struct llbitmap *llbitmap, sector_t offset,
> + unsigned long sectors)
> +{
> + struct mddev *mddev = llbitmap->mddev;
> + sector_t boundary = mddev->reshape_position;
> +
> + if (!llbitmap_reshaping(llbitmap))
> + return false;
[Severity: High]
Can a concurrent reshape thread update mddev->reshape_position from MaxSector to
0 between reading it into boundary and the call to llbitmap_reshaping()?
If that happens, boundary holds MaxSector but llbitmap_reshaping() evaluates to
true. This would cause offset < MaxSector to evaluate to true, mapping the IO
to the new geometry before the array has actually reshaped the sector. Could
this race lead to data corruption?
> +
> + WARN_ON_ONCE(sectors && offset < boundary && offset + sectors > boundary);
> +
> + return mddev->reshape_backwards ? offset < boundary : offset >= boundary;
> +}
[ ... ]
> @@ -1549,7 +1627,11 @@ static bool llbitmap_blocks_synced(struct mddev *mddev, sector_t offset)
> {
> struct llbitmap *llbitmap = mddev->bitmap;
> unsigned long p = offset >> llbitmap->chunkshift;
[Severity: High]
Does this unconditionally use the old chunkshift to compute the bit index from
the raw sync offset?
During an interrupted reshape recovery, active IO computes the correct bit index
using llbitmap_encode_range() for the new geometry. However, functions like
llbitmap_blocks_synced(), llbitmap_skip_sync_blocks(), and llbitmap_start_sync()
receive raw physical sectors from md_do_sync() and completely bypass
llbitmap_prepare_range().
If reshape_chunksize differs from chunksize, will the sync thread calculate the
wrong bit index, read a clean bit instead of the dirty bit marked by active IO,
and silently skip synchronizing the dirty sectors?
> - enum llbitmap_state c = llbitmap_read(llbitmap, p);
> + enum llbitmap_state c;
> +
> + if (p >= llbitmap->chunks)
> + return false;
> + c = llbitmap_read(llbitmap, p);
>
> return c == BitClean || c == BitDirty || c == BitCleanUnwritten;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=10
^ permalink raw reply
* Re: [PATCH v2 07/20] md/md-llbitmap: track target reshape geometry fields
From: sashiko-bot @ 2026-06-24 7:07 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <5440f676d6637f4c0262862252191c2244363087.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete teardown of the `pending_timer` and `daemon_work` cycle in `llbitmap_destroy` leads to a Use-After-Free.
- [High] Concurrent array resize causes Use-After-Free on the `llbitmap->pctl` array due to lack of I/O suspension.
--
commit 2a89e33f120722b7687d6b24f4bf95273fa7a498
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: track target reshape geometry fields
Track llbitmap bookkeeping for the target reshape geometry while keeping
a single live bitmap instance.
Add the reshape geometry fields, refresh helper, and update the load and
resize paths to keep the target geometry in sync.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 98e7824c7362e..cdced2126e975 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -289,6 +289,9 @@ struct llbitmap {
> unsigned long chunks;
> /* total number of sectors tracked by current bitmap geometry */
> sector_t sync_size;
> + unsigned long reshape_chunksize;
> + unsigned long reshape_chunks;
> + sector_t reshape_sync_size;
> unsigned long last_end_sync;
> /*
> * time in seconds that dirty bits will be cleared if the page is not
[Severity: High]
This isn't a bug introduced by this patch, but is there a use-after-free risk
during llbitmap teardown?
If a user removes the bitmap via the location sysfs node,
llbitmap_destroy() deletes the pending_timer and flushes the I/O workqueue:
drivers/md/md-llbitmap.c:llbitmap_destroy() {
...
timer_delete_sync(&llbitmap->pending_timer);
flush_workqueue(md_llbitmap_io_wq);
...
}
However, it doesn't seem to set a shutdown flag to prevent re-arming.
If the daemon work is executing and finds unexpired dirty pages, it will set
restart = true and unconditionally re-arm the timer:
drivers/md/md-llbitmap.c:md_llbitmap_daemon_fn() {
...
if (restart)
mod_timer(&llbitmap->pending_timer,
jiffies + llbitmap->mddev->bitmap_info.daemon_sleep * HZ);
}
Once the work finishes, the flush_workqueue() call in llbitmap_destroy()
returns and the llbitmap structure is freed. Can the re-armed timer then
fire on the freed llbitmap structure?
[Severity: High]
This is a pre-existing issue, but can concurrent array resizing cause a
use-after-free on the llbitmap->pctl array?
When expanding the array size via sysfs, update_size() invokes the
personality resize hook without suspending the array:
drivers/md/md.c:update_size() {
...
rv = mddev->pers->resize(mddev, num_sectors);
...
}
This eventually calls llbitmap_expand_pages(), which allocates a new
pointer array and immediately frees the old one:
drivers/md/md-llbitmap.c:llbitmap_expand_pages() {
...
kfree(llbitmap->pctl);
llbitmap->pctl = pctl;
...
}
Since update_size() only holds the mddev_lock and does not drain in-flight
I/O, new I/O can still be issued.
Could a concurrent I/O path calling llbitmap_raise_barrier() fetch the old
llbitmap->pctl array pointer just before it is freed:
drivers/md/md-llbitmap.c:llbitmap_raise_barrier() {
struct llbitmap_page_ctl *pctl = llbitmap->pctl[page_idx];
...
}
and then dereference it, accessing freed memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=7
^ permalink raw reply
* Re: [PATCH v2 13/20] md/md-llbitmap: clamp state-machine walks to tracked bits
From: sashiko-bot @ 2026-06-24 7:06 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <2f58279987b8b8b3f5b2ed8e563512524c530297.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] llbitmap_cond_end_sync prematurely marks partially synced chunks as completed, risking data corruption and skipped resyncs.
--
commit e55ca490604a05215923d84a1b1272a73343ea48
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: clamp state-machine walks to tracked bits
This commit adds bounds checking to llbitmap_state_machine() to prevent
walking past the tracked bitmap chunks. It ensures the state machine range
is clamped when the requested end bit exceeds the tracked boundary.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 00b77ecd600be..581ee9e4a3467 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -983,7 +983,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;
> while (start <= end) {
[Severity: Critical]
This is a pre-existing issue, but does the inclusive bound here cause
prematurely completed resyncs?
Looking at llbitmap_cond_end_sync(), it passes the current sector's chunk
index as the end bit:
drivers/md/md-llbitmap.c:llbitmap_cond_end_sync() {
...
llbitmap_state_machine(llbitmap, 0, sector >> llbitmap->chunkshift,
BitmapActionEndsync);
...
}
Because the while loop condition is start <= end, the chunk currently
undergoing resync will be included in BitmapActionEndsync and transition to
BitDirty prematurely.
If start_sync() is subsequently called for the remainder of this chunk,
won't it see BitDirty and return false? This would cause the resync loop
to interpret it as no resync needed, skipping the rest of the chunk's
sectors and leaving them out of sync.
Should the end parameter be treated as exclusive instead, or does
llbitmap_cond_end_sync() need to subtract one from the end chunk when
sector is not aligned to the chunk size?
> enum llbitmap_state c = llbitmap_read(llbitmap, start);
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=13
^ permalink raw reply
* Re: [PATCH v2 12/20] md/md-llbitmap: remap checkpointed bits as reshape progresses
From: sashiko-bot @ 2026-06-24 7:04 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <8700112d660a7f9fa48d174ee9b395fbe309e7c9.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] In-place array modification during reshape overwrites un-reshaped source data before it can be read.
- [High] Non-atomic read-modify-write cycle in `llbitmap_reshape_merge` races with concurrent normal I/O, dropping `BitDirty` flags.
- [High] Missing handling for `BitNeedSyncUnwritten` and `BitCleanUnwritten` in `llbitmap_rmerge_state` silently demotes them.
- [High] The `level_456` condition in `llbitmap_rmerge_state` is completely ineffective and subsumed by the subsequent fallback.
--
commit a1307817c41ef916bb59f41a3af5b2d7a709caa2
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: remap checkpointed bits as reshape progresses
Merge checkpointed old llbitmap state forward as reshape_position
advances and record the checkpoint remap through reshape_mark().
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index c62397743d9a0..00b77ecd600be 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> @@ -906,6 +914,33 @@ static int llbitmap_prepare_resize(struct llbitmap *llbitmap,
> return 0;
> }
>
> +static enum llbitmap_state
> +llbitmap_rmerge_state(struct llbitmap *llbitmap,
> + enum llbitmap_state dst,
> + enum llbitmap_state src)
> +{
> + bool level_456 = raid_is_456(llbitmap->mddev);
> +
> + if (dst == BitNeedSync || dst == BitSyncing ||
> + src == BitNeedSync || src == BitSyncing)
> + return BitNeedSync;
[Severity: High]
Are BitNeedSyncUnwritten and BitCleanUnwritten states meant to be handled
here?
Because they do not match BitNeedSync, BitSyncing, BitDirty, or BitClean,
they fall through these conditions. If paired with BitClean, they
incorrectly evaluate to BitClean; otherwise, they fall through to
BitUnwritten. Both outcomes silently drop the sync requirement.
> +
> + if (dst == BitDirty || src == BitDirty)
> + return BitDirty;
> +
> + /*
> + * Reshape generates valid target parity/data for both already-written
> + * and not-yet-written regions in the checkpointed range, so a mix of
> + * clean and unwritten still results in a clean destination bit.
> + */
> + if (level_456 && ((dst == BitClean && src == BitUnwritten) ||
> + (src == BitClean && dst == BitUnwritten)))
> + return BitClean;
> + if (dst == BitClean || src == BitClean)
> + return BitClean;
[Severity: High]
Does the fallback condition "dst == BitClean || src == BitClean" render the
preceding level_456 check dead code?
The fallback unconditionally forces any BitClean mix to BitClean, which
entirely overrides the level_456 restriction. Could this lead to RAID10
incorrectly resolving mixed BitClean and BitUnwritten states to BitClean,
causing skipped resync operations?
> + return BitUnwritten;
> +}
[ ... ]
> +static void llbitmap_reshape_merge(struct llbitmap *llbitmap,
> + const struct llbitmap_reshape_range *old,
> + const struct llbitmap_reshape_range *new)
> +{
> + unsigned long dst_start;
> + unsigned long dst_end;
> + unsigned long dst;
> +
> + if (!new->sectors)
> + return;
> +
> + dst_start = div64_u64(new->offset, llbitmap->reshape_chunksize);
> + dst_end = div64_u64(new->end - 1, llbitmap->reshape_chunksize);
> +
> + for (dst = dst_start; dst <= dst_end; dst++) {
> + struct llbitmap_reshape_range dst_range;
> + struct llbitmap_reshape_range src;
> + enum llbitmap_state state;
> +
> + llbitmap_reshape_dst_range(llbitmap, dst, new, &dst_range);
> + state = llbitmap_reshape_init_dst(llbitmap, dst, new);
[Severity: High]
Does this non-atomic read-modify-write cycle race with concurrent normal I/O?
llbitmap_reshape_init_dst() reads the chunk state, computes the merged state
through llbitmap_rmerge_src(), and writes it back via llbitmap_write() below
without being protected by locks.
Concurrent normal I/O operating on stripes outside the reshape window but
within the same bitmap chunk can set BitDirty. The llbitmap_reshape_merge()
thread will blindly overwrite this BitDirty flag with its locally computed
state, potentially causing silent data corruption due to lost BitDirty
flags.
> + if (llbitmap_reshape_src_range(old, new, &dst_range, &src))
> + state = llbitmap_rmerge_src(llbitmap, state, &src);
> + else
> + state = llbitmap_rmerge_state(llbitmap, state, BitUnwritten);
> + llbitmap_write(llbitmap, state, dst);
[Severity: Critical]
Does writing directly to the shared pctl array overwrite un-reshaped source
data before it can be read?
When adding disks to a RAID5 array, new->sectors > old->sectors. This causes
the forward iteration of dst to outpace bit in llbitmap_rmerge_src()
(e.g., dst = 10, bit = 5).
Because llbitmap_write() updates the array in place, the state at index 5
is overwritten before it is read for dst = 10, destroying the original chunk
state.
> + }
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=12
^ permalink raw reply
* Re: [PATCH v2 09/20] md/md-llbitmap: refuse reshape while llbitmap still needs sync
From: sashiko-bot @ 2026-06-24 7:04 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <fde37bced9be5e6b4d0f71cdd7d33d9387c022f6.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] llbitmap_reshape_can_start() fails to reject reshape when chunks are in BitNeedSyncUnwritten or BitSyncingUnwritten states.
- [High] The newly introduced reshape_can_start callback is never invoked by the RAID5 subsystem, rendering the reshape refusal logic non-functional for RAID5/6.
--
commit fc17ecb84d03fe66b3e1048dc17b6b8022da7f9b
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: refuse reshape while llbitmap still needs sync
Reject reshape when llbitmap still contains NeedSync or Syncing bits.
This keeps reshape from starting until the current llbitmap state has
been reconciled.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index ae2e87fd58874..11fede1fc79fd 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -1680,6 +1680,29 @@ static void llbitmap_dirty_bits(struct mddev *mddev, unsigned long s,
> llbitmap_state_machine(mddev->bitmap, s, e, BitmapActionStartwrite);
> }
>
> +static int llbitmap_reshape_can_start(struct mddev *mddev)
> +{
> + struct llbitmap *llbitmap = mddev->bitmap;
> + unsigned long chunk;
> + int ret = 0;
> +
> + if (!llbitmap)
> + return 0;
> +
> + mutex_lock(&mddev->bitmap_info.mutex);
> + for (chunk = 0; chunk < llbitmap->chunks; chunk++) {
> + enum llbitmap_state state = llbitmap_read(llbitmap, chunk);
> +
> + if (state == BitNeedSync || state == BitSyncing) {
[Severity: High]
Should this check also include BitNeedSyncUnwritten and BitSyncingUnwritten
states?
Reshaping an array while it has regions pending or undergoing proactive parity
synchronization could change the array layout while the background sync process
is running, potentially leading to corrupt parity.
> + ret = -EBUSY;
> + break;
> + }
> + }
> + mutex_unlock(&mddev->bitmap_info.mutex);
> +
> + return ret;
> +}
> +
[ ... ]
> @@ -2002,6 +2025,7 @@ static struct bitmap_operations llbitmap_ops = {
> .dirty_bits = llbitmap_dirty_bits,
> .prepare_range = llbitmap_prepare_range,
> .reshape_finish = llbitmap_reshape_finish,
> + .reshape_can_start = llbitmap_reshape_can_start,
[Severity: High]
Is the reshape_can_start callback invoked by the RAID5 subsystem when starting
a reshape?
Looking at raid5_start_reshape() in drivers/md/raid5.c:
if (md_bitmap_enabled(mddev, false) &&
mddev->bitmap_id == ID_LLBITMAP) {
i = mddev->bitmap_ops->resize(mddev, mddev->dev_sectors, 0);
It doesn't appear to call mddev->bitmap_ops->reshape_can_start. This could
allow RAID5/6 arrays to start a reshape while the bitmap still contains
pending sync bits, causing the array layout to change before parity is
reconciled.
> .write_all = llbitmap_write_all,
>
> .groups = md_llbitmap_groups,
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=9
^ permalink raw reply
* Re: [PATCH v2 02/20] md: skip bitmap accounting for empty write ranges
From: sashiko-bot @ 2026-06-24 7:04 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <d978c0c72c874d7033b0806a2dba255d6ff9e359.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Using `md_io_clone->start_time == 0` to check whether IO accounting was started is unsafe because `jiffies` can legitimately be exactly 0, permanently leaking the device's `in_flight` counter.
--
commit ff695222c639e0740f645b5e4a15298c468511f4
Author: Yu Kuai <yukuai@fygo.io>
md: skip bitmap accounting for empty write ranges
This commit updates md bitmap accounting to handle zero-sector flush/FUA bios.
It treats both naturally empty bios and ranges trimmed by the prepare_range
hook as not started, preventing the completion path from calling end_write()
on an empty range.
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 3b20a57b8c7ed..0b59c676f7c03 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
[ ... ]
> @@ -9423,10 +9426,12 @@ static void md_clone_bio(struct mddev *mddev, struct bio **bio)
> md_io_clone = container_of(clone, struct md_io_clone, bio_clone);
> md_io_clone->orig_bio = *bio;
> md_io_clone->mddev = mddev;
> + md_io_clone->sectors = 0;
> if (blk_queue_io_stat(bdev->bd_disk->queue))
> md_io_clone->start_time = bio_start_io_acct(*bio);
[Severity: High]
This isn't a bug introduced by this patch, but is it safe to use
md_io_clone->start_time as a boolean flag to track if IO accounting was
started?
Looking at bio_start_io_acct(), it returns the current jiffies value. If an
IO request is submitted exactly when the jiffies counter wraps to 0,
start_time will be set to 0.
When the IO completes, md_end_clone_io() evaluates the following condition:
if (md_io_clone->start_time)
bio_end_io_acct(orig_bio, md_io_clone->start_time);
If start_time happens to be 0, it skips bio_end_io_acct() and the block
device's in_flight counter is permanently leaked. This prevents
is_mddev_idle() from ever returning true, which could permanently throttle
background sync operations until the system is rebooted.
> - if (bio_data_dir(*bio) == WRITE && md_bitmap_enabled(mddev, false)) {
> + if (bio_data_dir(*bio) == WRITE && bio_sectors(*bio) &&
> + md_bitmap_enabled(mddev, false)) {
> md_io_clone->offset = (*bio)->bi_iter.bi_sector;
> md_io_clone->sectors = bio_sectors(*bio);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=2
^ permalink raw reply
* Re: [PATCH v2 06/20] md/md-llbitmap: grow the page cache in place for reshape
From: sashiko-bot @ 2026-06-24 7:03 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <27639f9aceb3cb6d6d021df79f9f6839d916bb58.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The `LLPageFlush` bit on existing cached pages is set during `llbitmap_flush()` but never cleared, permanently bypassing the barrier idle expiration timer and causing severe metadata write amplification.
- [High] Reallocating `llbitmap->pctl` locklessly in place causes a Use-After-Free for concurrent I/O paths and the background daemon.
Pre-existing issues:
- [High] An integer overflow in chunk size calculation on 32-bit systems causes a fatal divide-by-zero for extremely large arrays.
--
commit 06efa66cdd24523c6bea3b2de073842d179f3506
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: grow the page cache in place for reshape
Use the page-control helpers to grow llbitmap's cached pages in place
for resize and later reshape preparation, instead of rebuilding the
whole cache.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index 4c3fc4b35aff0..98e7824c7362e 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -416,6 +416,19 @@ static char state_machine[BitStateCount][BitmapActionCount] = {
> };
>
> static void __llbitmap_flush(struct mddev *mddev);
> +static void llbitmap_flush(struct mddev *mddev);
> +static void llbitmap_update_sb(void *data);
> +
> +static void llbitmap_calculate_chunks(struct mddev *mddev, sector_t blocks,
> + unsigned long *chunksize,
> + unsigned long *chunks)
> +{
> + *chunks = DIV_ROUND_UP_SECTOR_T(blocks, *chunksize);
> + while (*chunks > mddev->bitmap_info.space << SECTOR_SHIFT) {
> + *chunksize = *chunksize << 1;
> + *chunks = DIV_ROUND_UP_SECTOR_T(blocks, *chunksize);
[Severity: High]
This isn't a bug introduced by this patch, but since `chunksize` is an
`unsigned long` (32 bits on 32-bit architectures) and `blocks` is a 64-bit
`sector_t`, could the left shift push `*chunksize` past 31 bits and overflow
it to 0 for extremely large arrays?
If `*chunksize` becomes 0, does this cause a divide-by-zero panic in the
`DIV_ROUND_UP_SECTOR_T()` macro?
> + }
> +}
[ ... ]
> +static int llbitmap_expand_pages(struct llbitmap *llbitmap,
> + unsigned long chunks)
> +{
> + struct llbitmap_page_ctl **pctl;
> + unsigned int old_nr_pages = llbitmap->nr_pages;
> + unsigned int nr_pages = llbitmap_used_pages(llbitmap, chunks);
> + unsigned int i;
> + int ret;
> +
> + if (nr_pages <= old_nr_pages)
> + return 0;
> +
> + pctl = kcalloc(nr_pages, sizeof(*pctl), GFP_KERNEL);
> + if (!pctl)
> + return -ENOMEM;
> +
> + if (llbitmap->pctl)
> + memcpy(pctl, llbitmap->pctl,
> + array_size(old_nr_pages, sizeof(*pctl)));
> +
> + for (i = old_nr_pages; i < nr_pages; i++) {
> + pctl[i] = llbitmap_alloc_page_ctl(llbitmap, i);
> + if (IS_ERR(pctl[i]))
> + goto err_alloc_ptr;
> + }
> +
> + kfree(llbitmap->pctl);
> + llbitmap->pctl = pctl;
> + llbitmap->nr_pages = nr_pages;
[Severity: High]
Is it safe to reallocate and update `llbitmap->pctl` and `nr_pages` locklessly
in place like this while the array is processing I/O?
`llbitmap_resize()` holds only `mddev->bitmap_info.mutex`, but concurrent
lockless readers like `md_llbitmap_daemon_fn()` and the I/O fastpath
`llbitmap_start_write()` dereference `llbitmap->pctl[idx]`.
Could this lead to a Use-After-Free if a concurrent reader accesses the old
`llbitmap->pctl` array just as it gets freed?
> + return 0;
> +
> +err_alloc_ptr:
> + ret = PTR_ERR(pctl[i]);
[ ... ]
> +static int llbitmap_prepare_resize(struct llbitmap *llbitmap,
> + unsigned long old_chunks,
> + unsigned long new_chunks,
> + unsigned long cache_chunks)
> +{
> + int ret;
> +
> + llbitmap_flush(llbitmap->mddev);
> + ret = llbitmap_expand_pages(llbitmap, cache_chunks);
[Severity: High]
Does this sequence cause the daemon thread to bypass the barrier idle timer and
create severe metadata write amplification?
`llbitmap_flush()` sets the `LLPageFlush` bit on all existing pages. Since
`llbitmap_expand_pages()` reuses the existing `pctl` structures, the active
pages are retained with the `LLPageFlush` bit still set.
Since this bit is never cleared, the check in `md_llbitmap_daemon_fn()`:
if (!test_bit(LLPageFlush, &pctl->flags) &&
time_before(jiffies, pctl->expire)) {
restart = true;
continue;
}
will permanently fail for these pages, forcing the daemon to immediately flush
them and skip re-arming the pending timer.
> + if (ret)
> + return ret;
> + if (new_chunks > old_chunks)
> + llbitmap_mark_range(llbitmap, old_chunks, new_chunks - 1,
> + BitUnwritten);
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=6
^ permalink raw reply
* Re: [PATCH v2 04/20] md/md-llbitmap: track bitmap sync_size explicitly
From: sashiko-bot @ 2026-06-24 7:02 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <2fd017b2cb7bbeb49f0a1b8e0d413c0822f80885.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Data race on `llbitmap->sync_size` between `llbitmap_resize` and `llbitmap_update_sb` can result in a corrupted superblock.
Pre-existing issues:
- [Critical] Improper teardown order in `llbitmap_destroy()` allows the asynchronous workqueue to unsafely re-arm the timer, leading to a Use-After-Free.
--
commit 4f14b77c13988c93db9a3db0e4720c69a8ac613c
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: track bitmap sync_size explicitly
Track llbitmap's own sync_size instead of always using
mddev->resync_max_sectors directly. This is the minimal bookkeeping
needed before llbitmap can track old and new reshape geometry
independently.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index f0c20afa354eb..e3500a1a52c07 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> @@ -1153,6 +1161,7 @@ static int llbitmap_resize(struct mddev *mddev, sector_t blocks, int chunksize)
> llbitmap->chunkshift = ffz(~chunksize);
> llbitmap->chunksize = chunksize;
> llbitmap->chunks = chunks;
> + llbitmap->sync_size = blocks;
>
> return 0;
> }
[ ... ]
> @@ -1526,7 +1535,7 @@ static void llbitmap_update_sb(void *data)
> sb->events = cpu_to_le64(mddev->events);
> sb->state = cpu_to_le32(llbitmap->flags);
> sb->chunksize = cpu_to_le32(llbitmap->chunksize);
> - sb->sync_size = cpu_to_le64(mddev->resync_max_sectors);
> + sb->sync_size = cpu_to_le64(llbitmap->sync_size);
[Severity: High]
Can this read of llbitmap->sync_size cause a torn read on 32-bit systems?
While llbitmap_resize() updates this 64-bit value while holding
mddev->bitmap_info.mutex and reconfig_mutex, md_update_sb() calls
llbitmap_update_sb() without holding bitmap_info.mutex.
If a torn read occurs during concurrent array resize operations, could the
superblock be written with a corrupted sync_size? This might lead to array
assembly failures or out-of-bounds accesses during subsequent operations.
[ ... ]
[Severity: Critical]
This is a pre-existing issue, but does the teardown sequence in
llbitmap_destroy() have a use-after-free risk for the timer?
Looking at the current teardown order in llbitmap_destroy():
llbitmap_destroy() {
...
timer_delete_sync(&llbitmap->pending_timer);
flush_workqueue(md_llbitmap_io_wq);
...
}
If md_llbitmap_daemon_fn() is running during the flush_workqueue() call,
it might attempt to re-arm the timer:
md_llbitmap_daemon_fn() {
...
if (restart)
mod_timer(&llbitmap->pending_timer, jiffies + ...);
}
Could the asynchronous workqueue unsafely re-arm the timer here, allowing
it to resurrect after timer_delete_sync() and execute after the llbitmap
structure has been freed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=4
^ permalink raw reply
* Re: [PATCH v2 05/20] md/md-llbitmap: allocate page controls independently
From: sashiko-bot @ 2026-06-24 7:02 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <6e1ca7ea2cb90ae58c47230a90f3f08d51658829.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] Eager allocation of physical memory and disk I/O for the entire unused reserved bitmap space causes severe memory consumption and I/O stall regressions.
Pre-existing issues:
- [Critical] The bitmap space validation omits BITMAP_DATA_OFFSET, potentially allowing the bitmap to overflow its physical bounds and corrupt user data.
--
commit 880054f58bccd2442566ac1e584d6d9c8fc01e7e
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: allocate page controls independently
Allocate one llbitmap page-control object at a time and free each
object through the same model.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index e3500a1a52c07..4c3fc4b35aff0 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
[ ... ]
> +static int llbitmap_alloc_pages(struct llbitmap *llbitmap)
> +{
> + unsigned int used_pages = llbitmap_used_pages(llbitmap, llbitmap->chunks);
> + unsigned int nr_pages = max(used_pages, llbitmap_reserved_pages(llbitmap));
> + int i;
[Severity: High]
Does this unconditionally eager-allocate memory and write out the entire
reserved space?
By setting nr_pages to the maximum reserved space:
nr_pages = max(used_pages, llbitmap_reserved_pages(llbitmap));
and unconditionally allocating a physical 4KB page for every index up to
this limit in llbitmap_read_page(), this seems to allocate RAM for all
reserved, unused pages.
Furthermore, will functions like __llbitmap_flush() now iterate over all
these allocated nr_pages, marking them dirty and synchronously writing them
to disk, potentially causing severe I/O stalls for arrays with large
reserved bitmap spaces?
> +
> + llbitmap->pctl = kcalloc(nr_pages, sizeof(*llbitmap->pctl), GFP_KERNEL);
> + if (!llbitmap->pctl)
> + return -ENOMEM;
[ ... ]
> @@ -923,7 +948,7 @@ static int llbitmap_init(struct llbitmap *llbitmap)
> llbitmap->sync_size = blocks;
> mddev->bitmap_info.daemon_sleep = DEFAULT_DAEMON_SLEEP;
>
> - ret = llbitmap_cache_pages(llbitmap);
> + ret = llbitmap_alloc_pages(llbitmap);
[Severity: Critical]
This is a pre-existing issue, but does the bitmap space validation here
omit BITMAP_DATA_OFFSET?
In llbitmap_init() and llbitmap_read_sb(), the validation checks ensure
the total bitmap size (chunks) doesn't exceed the reserved byte length
(space). However, they don't seem to account for the 1024-byte
BITMAP_DATA_OFFSET that is prepended to the bitmap data on disk.
If chunks is close to or exactly equal to space, the total byte size
required (chunks + BITMAP_DATA_OFFSET) could exceed the physical bounds
of the reserved space. During flushes, could llbitmap_write_page() write
across the reserved bitmap boundary and overwrite adjacent user data?
> if (ret)
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=5
^ permalink raw reply
* Re: [PATCH v2 03/20] md: add helper to split bios at reshape offset
From: sashiko-bot @ 2026-06-24 7:01 UTC (permalink / raw)
To: Yu Kuai; +Cc: linux-raid, yukuai
In-Reply-To: <20e701b8355e1efd0d7cff3265189abf2424400b.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Lockless read of 64-bit `mddev->reshape_position` risks torn reads on 32-bit architectures and TOCTOU races between bio splitting and bitmap accounting, leading to silent data corruption.
--
commit 4912480eb23a69a6634d083e53f12568752eafb0
Author: Yu Kuai <yukuai@fygo.io>
md: add helper to split bios at reshape offset
This commit adds the mddev_bio_split_at_reshape_offset() helper function.
It allows MD personalities to share the reshape-offset bio splitting logic
instead of open-coding it in multiple places.
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 0b59c676f7c03..c18a7f3c27e65 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
[ ... ]
> @@ -9361,6 +9361,45 @@ void md_submit_discard_bio(struct mddev *mddev, struct md_rdev *rdev,
> }
> EXPORT_SYMBOL_GPL(md_submit_discard_bio);
>
> +struct bio *mddev_bio_split_at_reshape_offset(struct mddev *mddev,
> + struct bio *bio,
> + unsigned int *max_sectors,
> + struct bio_set *bs)
> +{
> + sector_t boundary;
> + sector_t start;
> + sector_t end;
> + unsigned int split_sectors;
> +
> + split_sectors = bio_sectors(bio);
> + if (max_sectors && *max_sectors && *max_sectors < split_sectors)
> + split_sectors = *max_sectors;
> +
> + if (!test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery))
> + goto split;
> +
> + boundary = mddev->reshape_position;
[Severity: Critical]
Can this lockless read of mddev->reshape_position cause a torn read on
32-bit architectures since it is a 64-bit value?
Additionally, does reading this without locking introduce a time-of-check to
time-of-use race with bitmap accounting? If mddev->reshape_position
is updated by the reshape thread after this split check, but before bitmap
accounting in llbitmap_map_previous(), an unsplit bio could end up crossing
the new boundary.
This could trigger the WARN_ON_ONCE in llbitmap_map_previous():
sector_t boundary = mddev->reshape_position;
if (!llbitmap_reshaping(llbitmap))
return false;
WARN_ON_ONCE(sectors && offset < boundary && offset + sectors > boundary);
Could this race result in a bio being mis-accounted to the wrong array
geometry, potentially causing data corruption if a crash occurs during a
reshape?
> + start = bio->bi_iter.bi_sector;
> + end = bio_end_sector(bio);
> + if (start >= boundary || end <= boundary)
> + goto split;
> +
> + if (boundary - start < split_sectors)
> + split_sectors = boundary - start;
> +
> +split:
> + if (max_sectors)
> + *max_sectors = split_sectors;
> + if (split_sectors < bio_sectors(bio)) {
> + bio = bio_submit_split_bioset(bio, split_sectors, bs);
> + if (bio)
> + bio->bi_opf |= REQ_NOMERGE;
> + }
> +
> + return bio;
> +}
> +EXPORT_SYMBOL_GPL(mddev_bio_split_at_reshape_offset);
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=3
^ permalink raw reply
* Re: [PATCH v2 11/20] md/md-llbitmap: don't skip reshape ranges from bitmap state
From: sashiko-bot @ 2026-06-24 6:58 UTC (permalink / raw)
To: Yu Kuai; +Cc: yukuai, linux-raid
In-Reply-To: <11d028037df1acf02db6d67a362ab02e96a7dd57.1782282042.git.yukuai@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Use-After-Free (UAF) of `llbitmap` memory during dynamic bitmap unregistration.
- [High] Signed integer overflow in `llbitmap_skip_sync_blocks` can cause premature resync termination.
--
commit 008d5398fa7aa1473594e503af861f03ef4f2548
Author: Yu Kuai <yukuai@fygo.io>
md/md-llbitmap: don't skip reshape ranges from bitmap state
Reshape progress is tracked by array metadata rather than llbitmap.
Do not let llbitmap skip_sync_blocks() suppress reshape ranges based on
stale bitmap state before the corresponding checkpoint is persisted.
> diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
> index d27993cfb13da..c62397743d9a0 100644
> --- a/drivers/md/md-llbitmap.c
> +++ b/drivers/md/md-llbitmap.c
> @@ -1647,6 +1647,14 @@ static sector_t llbitmap_skip_sync_blocks(struct mddev *mddev, sector_t offset)
> return 0;
> c = llbitmap_read(llbitmap, p);
>
> + /*
> + * Reshape progress is tracked by array metadata rather than llbitmap.
> + * Skipping reshape ranges from stale bitmap state can lose data after a
> + * restart before the corresponding bits are checkpointed to disk.
> + */
> + if (test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery))
> + return 0;
> +
> /* always skip unwritten blocks */
> if (c == BitUnwritten)
> return blocks;
[Severity: High]
This is a pre-existing issue, but since we are modifying this function, is
there a risk of signed integer overflow when returning blocks here?
If the array is extremely large and reserved bitmap space is small,
llbitmap->chunksize can be doubled during initialization until it exceeds
INT_MAX.
Because blocks is calculated earlier in this function as an int:
int blocks = llbitmap->chunksize - (offset & (llbitmap->chunksize - 1));
If chunksize exceeds INT_MAX, blocks could become negative.
When this negative value is implicitly cast to the sector_t (unsigned 64-bit)
return type, it becomes a massive positive number.
Could this cause md_do_sync() to jump to the end of the array and
prematurely abort the synchronization?
Would it be safer to change the type of blocks to unsigned long or sector_t?
[Severity: Critical]
This isn't a bug introduced by this patch, but looking at the teardown
sequence elsewhere in this file for dynamic bitmap unregistration, does
llbitmap_destroy() have a use-after-free vulnerability?
When clearing the bitmap at runtime, llbitmap_destroy() deletes the timer
and flushes the workqueues without setting the LLPageFlush flag:
timer_delete_sync(&llbitmap->pending_timer);
flush_workqueue(md_llbitmap_io_wq);
flush_workqueue(md_llbitmap_unplug_wq);
mddev->bitmap = NULL;
llbitmap_free_pages(llbitmap);
kfree(llbitmap);
If the daemon worker (md_llbitmap_daemon_fn) is running on the workqueue,
timer_delete_sync() might do nothing if the timer already fired. The
flush_workqueue() call then waits for the worker to finish.
Inside the worker, because LLPageFlush is not set and idle pages have an
expire of LONG_MAX, it sets restart = true and re-arms the timer:
if (!test_bit(LLPageFlush, &pctl->flags) &&
time_before(jiffies, pctl->expire)) {
restart = true;
continue;
}
...
if (restart)
mod_timer(&llbitmap->pending_timer, ...);
Once the worker finishes, flush_workqueue() returns and llbitmap is freed.
Does this leave the timer armed on freed memory, potentially causing memory
corruption when it fires?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782282042.git.yukuai@kernel.org?part=11
^ permalink raw reply
* [PATCH v2 20/20] md/raid5: split reshape bios before bitmap accounting
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
Use the shared mddev_bio_split_at_reshape_offset() helper so RAID5
submits only one-side bios to llbitmap during reshape.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid5.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index ac7ea483502f..fb346a3c4aa3 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6181,6 +6181,14 @@ static bool raid5_make_request(struct mddev *mddev, struct bio * bi)
return true;
}
+ bi = mddev_bio_split_at_reshape_offset(mddev, bi, NULL,
+ &conf->bio_split);
+ if (!bi) {
+ if (rw == WRITE)
+ md_write_end(mddev);
+ return true;
+ }
+
logical_sector = bi->bi_iter.bi_sector & ~((sector_t)RAID5_STRIPE_SECTORS(conf)-1);
bi->bi_next = NULL;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 19/20] md/raid5: wire llbitmap reshape lifecycle
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
Prepare llbitmap before RAID5 reshape starts, checkpoint the bitmap
before advancing reshape_position, and finish the llbitmap geometry
update when reshape completes.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid5.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 9de648f75dd0..ac7ea483502f 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6430,6 +6430,13 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
|| test_bit(MD_RECOVERY_INTR, &mddev->recovery));
if (atomic_read(&conf->reshape_stripes) != 0)
return 0;
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_mark &&
+ conf->reshape_safe != conf->reshape_progress) {
+ mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
+ conf->reshape_progress);
+ mddev->bitmap_ops->unplug(mddev, true);
+ }
mddev->reshape_position = conf->reshape_progress;
mddev->curr_resync_completed = sector_nr;
if (!mddev->reshape_backwards)
@@ -6539,6 +6546,13 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr, int *sk
|| test_bit(MD_RECOVERY_INTR, &mddev->recovery));
if (atomic_read(&conf->reshape_stripes) != 0)
goto ret;
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_mark &&
+ conf->reshape_safe != conf->reshape_progress) {
+ mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
+ conf->reshape_progress);
+ mddev->bitmap_ops->unplug(mddev, true);
+ }
mddev->reshape_position = conf->reshape_progress;
mddev->curr_resync_completed = sector_nr;
if (!mddev->reshape_backwards)
@@ -8571,6 +8585,12 @@ static int raid5_start_reshape(struct mddev *mddev)
mdname(mddev));
return -EINVAL;
}
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_id == ID_LLBITMAP) {
+ i = mddev->bitmap_ops->resize(mddev, mddev->dev_sectors, 0);
+ if (i)
+ return i;
+ }
atomic_set(&conf->reshape_stripes, 0);
spin_lock_irq(&conf->device_lock);
@@ -8655,10 +8675,19 @@ static int raid5_start_reshape(struct mddev *mddev)
*/
static void end_reshape(struct r5conf *conf)
{
+ struct mddev *mddev = conf->mddev;
if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
struct md_rdev *rdev;
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_mark &&
+ conf->reshape_safe != conf->reshape_progress) {
+ mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
+ conf->reshape_progress);
+ mddev->bitmap_ops->unplug(mddev, true);
+ }
+
spin_lock_irq(&conf->device_lock);
conf->previous_raid_disks = conf->raid_disks;
md_finish_reshape(conf->mddev);
@@ -8685,8 +8714,16 @@ static void raid5_finish_reshape(struct mddev *mddev)
{
struct r5conf *conf = mddev->private;
struct md_rdev *rdev;
+ bool llbitmap = mddev->bitmap_id == ID_LLBITMAP &&
+ md_bitmap_enabled(mddev, false);
if (!test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
+ if (llbitmap && mddev->bitmap_ops->reshape_finish)
+ mddev->bitmap_ops->reshape_finish(mddev);
+ if (llbitmap) {
+ mddev->resync_offset = 0;
+ mddev->resync_max_sectors = mddev->dev_sectors;
+ }
if (mddev->delta_disks <= 0) {
int d;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 18/20] md/raid5: reject llbitmap reshape when md chunk shrinks
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
llbitmap reshape keeps one live bitmap and cannot safely make an
existing bitmap bit cover a smaller data range.
The llbitmap chunksize itself will not shrink when mddev->chunk_sectors
stays the same or grows. However, shrinking mddev->chunk_sectors shrinks
sectors_per_chunk used by raid5_bitmap_sector_map(). That can shrink the
effective data range covered by each bit across the old and new RAID5
geometry. Reject that reshape while llbitmap is active.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid5.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 1613a42cc25d..9de648f75dd0 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -8506,6 +8506,9 @@ static int check_reshape(struct mddev *mddev)
if (!check_stripe_cache(mddev))
return -ENOSPC;
+ if (mddev->bitmap_id == ID_LLBITMAP &&
+ mddev->new_chunk_sectors < mddev->chunk_sectors)
+ return -EOPNOTSUPP;
if (mddev->new_chunk_sectors > mddev->chunk_sectors ||
mddev->delta_disks > 0)
if (resize_chunks(conf,
--
2.51.0
^ permalink raw reply related
* [PATCH v2 17/20] md/raid5: add exact old and new llbitmap mapping helpers
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
Teach RAID5 to export exact old and new llbitmap mappings and the
corresponding sync and array sizes for reshape-aware bitmap users.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid5.c | 70 ++++++++++++++++++++++++++++++++++------------
1 file changed, 52 insertions(+), 18 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 0c5c9fb0606e..1613a42cc25d 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5942,25 +5942,43 @@ static enum reshape_loc get_reshape_loc(struct mddev *mddev,
return LOC_BEHIND_RESHAPE;
}
-static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
- unsigned long *sectors)
+static void raid5_bitmap_sector_map(struct mddev *mddev, sector_t *offset,
+ unsigned long *sectors,
+ bool previous)
{
struct r5conf *conf = mddev->private;
sector_t start = *offset;
sector_t end = start + *sectors;
- sector_t prev_start = start;
- sector_t prev_end = end;
int sectors_per_chunk;
- enum reshape_loc loc;
int dd_idx;
- sectors_per_chunk = conf->chunk_sectors *
- (conf->raid_disks - conf->max_degraded);
+ if (previous)
+ sectors_per_chunk = conf->prev_chunk_sectors *
+ (conf->previous_raid_disks - conf->max_degraded);
+ else
+ sectors_per_chunk = conf->chunk_sectors *
+ (conf->raid_disks - conf->max_degraded);
start = round_down(start, sectors_per_chunk);
end = round_up(end, sectors_per_chunk);
- start = raid5_compute_sector(conf, start, 0, &dd_idx, NULL);
- end = raid5_compute_sector(conf, end, 0, &dd_idx, NULL);
+ start = raid5_compute_sector(conf, start, previous, &dd_idx, NULL);
+ end = raid5_compute_sector(conf, end, previous, &dd_idx, NULL);
+ *offset = start;
+ *sectors = end - start;
+}
+
+static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
+ unsigned long *sectors)
+{
+ struct r5conf *conf = mddev->private;
+ sector_t start = *offset;
+ sector_t end = start + *sectors;
+ sector_t prev_start = start;
+ unsigned long prev_sectors = end - start;
+ enum reshape_loc loc;
+
+ raid5_bitmap_sector_map(mddev, &start, sectors, false);
+ end = start + *sectors;
/*
* For LOC_INSIDE_RESHAPE, this IO will wait for reshape to make
@@ -5969,17 +5987,10 @@ static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
loc = get_reshape_loc(mddev, conf, prev_start);
if (likely(loc != LOC_AHEAD_OF_RESHAPE)) {
*offset = start;
- *sectors = end - start;
return;
}
- sectors_per_chunk = conf->prev_chunk_sectors *
- (conf->previous_raid_disks - conf->max_degraded);
- prev_start = round_down(prev_start, sectors_per_chunk);
- prev_end = round_down(prev_end, sectors_per_chunk);
-
- prev_start = raid5_compute_sector(conf, prev_start, 1, &dd_idx, NULL);
- prev_end = raid5_compute_sector(conf, prev_end, 1, &dd_idx, NULL);
+ raid5_bitmap_sector_map(mddev, &prev_start, &prev_sectors, true);
/*
* for LOC_AHEAD_OF_RESHAPE, reshape can make progress before this IO
@@ -5987,7 +5998,7 @@ static void raid5_bitmap_sector(struct mddev *mddev, sector_t *offset,
* we set bits for both.
*/
*offset = min(start, prev_start);
- *sectors = max(end, prev_end) - *offset;
+ *sectors = max(end, prev_start + prev_sectors) - *offset;
}
static enum stripe_result make_stripe_request(struct mddev *mddev,
@@ -9049,6 +9060,20 @@ static void raid5_prepare_suspend(struct mddev *mddev)
wake_up(&conf->wait_for_reshape);
}
+static sector_t raid5_bitmap_sync_size(struct mddev *mddev, bool previous)
+{
+ return mddev->dev_sectors;
+}
+
+static sector_t raid5_bitmap_array_sectors(struct mddev *mddev, bool previous)
+{
+ struct r5conf *conf = mddev->private;
+
+ if (previous)
+ return raid5_size(mddev, 0, 0);
+ return raid5_size(mddev, mddev->dev_sectors, conf->raid_disks);
+}
+
static struct md_personality raid6_personality =
{
.head = {
@@ -9078,6 +9103,9 @@ static struct md_personality raid6_personality =
.change_consistency_policy = raid5_change_consistency_policy,
.prepare_suspend = raid5_prepare_suspend,
.bitmap_sector = raid5_bitmap_sector,
+ .bitmap_sector_map = raid5_bitmap_sector_map,
+ .bitmap_sync_size = raid5_bitmap_sync_size,
+ .bitmap_array_sectors = raid5_bitmap_array_sectors,
};
static struct md_personality raid5_personality =
{
@@ -9108,6 +9136,9 @@ static struct md_personality raid5_personality =
.change_consistency_policy = raid5_change_consistency_policy,
.prepare_suspend = raid5_prepare_suspend,
.bitmap_sector = raid5_bitmap_sector,
+ .bitmap_sector_map = raid5_bitmap_sector_map,
+ .bitmap_sync_size = raid5_bitmap_sync_size,
+ .bitmap_array_sectors = raid5_bitmap_array_sectors,
};
static struct md_personality raid4_personality =
@@ -9139,6 +9170,9 @@ static struct md_personality raid4_personality =
.change_consistency_policy = raid5_change_consistency_policy,
.prepare_suspend = raid5_prepare_suspend,
.bitmap_sector = raid5_bitmap_sector,
+ .bitmap_sector_map = raid5_bitmap_sector_map,
+ .bitmap_sync_size = raid5_bitmap_sync_size,
+ .bitmap_array_sectors = raid5_bitmap_array_sectors,
};
static int __init raid5_init(void)
--
2.51.0
^ permalink raw reply related
* [PATCH v2 16/20] md/raid10: split reshape bios before bitmap accounting
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
Use the shared mddev_bio_split_at_reshape_offset() helper so RAID10
submits only one-side bios to llbitmap during reshape.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid10.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e50e4adee389..fd364a2e2fd9 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1911,6 +1911,12 @@ static bool raid10_make_request(struct mddev *mddev, struct bio *bio)
sectors = chunk_sects -
(bio->bi_iter.bi_sector &
(chunk_sects - 1));
+
+ bio = mddev_bio_split_at_reshape_offset(mddev, bio, §ors,
+ &conf->bio_split);
+ if (!bio)
+ return true;
+
if (!__make_request(mddev, bio, sectors))
md_write_end(mddev);
--
2.51.0
^ permalink raw reply related
* [PATCH v2 15/20] md/raid10: wire llbitmap reshape lifecycle
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
Prepare llbitmap before RAID10 starts growing, checkpoint the bitmap
before advancing reshape_position, finish the llbitmap geometry update
when reshape completes, and export the old and new tracked sizes.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid10.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 1242b8d3bb6b..e50e4adee389 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4394,6 +4394,12 @@ static int raid10_start_reshape(struct mddev *mddev)
if (test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))
return -EBUSY;
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_can_start) {
+ ret = mddev->bitmap_ops->reshape_can_start(mddev);
+ if (ret)
+ return ret;
+ }
if (setup_geo(&new, mddev, geo_start) != conf->copies)
return -EINVAL;
@@ -4707,6 +4713,13 @@ static sector_t reshape_request(struct mddev *mddev, sector_t sector_nr,
time_after(jiffies, conf->reshape_checkpoint + 10*HZ)) {
/* Need to update reshape_position in metadata */
wait_barrier(conf, false);
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_mark &&
+ conf->reshape_safe != conf->reshape_progress) {
+ mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
+ conf->reshape_progress);
+ mddev->bitmap_ops->unplug(mddev, true);
+ }
mddev->reshape_position = conf->reshape_progress;
if (mddev->reshape_backwards)
mddev->curr_resync_completed = raid10_size(mddev, 0, 0)
@@ -4905,9 +4918,19 @@ static void reshape_request_write(struct mddev *mddev, struct r10bio *r10_bio)
static void end_reshape(struct r10conf *conf)
{
+ struct mddev *mddev = conf->mddev;
+
if (test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery))
return;
+ if (md_bitmap_enabled(mddev, false) &&
+ mddev->bitmap_ops->reshape_mark &&
+ conf->reshape_safe != conf->reshape_progress) {
+ mddev->bitmap_ops->reshape_mark(mddev, conf->reshape_safe,
+ conf->reshape_progress);
+ mddev->bitmap_ops->unplug(mddev, true);
+ }
+
spin_lock_irq(&conf->device_lock);
conf->prev = conf->geo;
md_finish_reshape(conf->mddev);
@@ -5039,10 +5062,15 @@ static void end_reshape_request(struct r10bio *r10_bio)
static void raid10_finish_reshape(struct mddev *mddev)
{
struct r10conf *conf = mddev->private;
+ bool llbitmap = mddev->bitmap_id == ID_LLBITMAP &&
+ md_bitmap_enabled(mddev, false);
if (test_bit(MD_RECOVERY_INTR, &mddev->recovery))
return;
+ if (llbitmap && mddev->bitmap_ops->reshape_finish)
+ mddev->bitmap_ops->reshape_finish(mddev);
+
if (mddev->delta_disks > 0) {
if (mddev->resync_offset > mddev->resync_max_sectors) {
mddev->resync_offset = mddev->resync_max_sectors;
@@ -5069,6 +5097,15 @@ static void raid10_finish_reshape(struct mddev *mddev)
mddev->reshape_backwards = 0;
}
+static sector_t raid10_bitmap_sync_size(struct mddev *mddev, bool previous)
+{
+ struct r10conf *conf = mddev->private;
+
+ if (previous)
+ return raid10_size(mddev, 0, 0);
+ return raid10_size(mddev, 0, conf->geo.raid_disks);
+}
+
static struct md_personality raid10_personality =
{
.head = {
@@ -5095,6 +5132,8 @@ static struct md_personality raid10_personality =
.start_reshape = raid10_start_reshape,
.finish_reshape = raid10_finish_reshape,
.update_reshape_pos = raid10_update_reshape_pos,
+ .bitmap_sync_size = raid10_bitmap_sync_size,
+ .bitmap_array_sectors = raid10_bitmap_sync_size,
};
static int __init raid10_init(void)
--
2.51.0
^ permalink raw reply related
* [PATCH v2 14/20] md/raid10: reject llbitmap reshape when md chunk shrinks
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
llbitmap reshape keeps one live bitmap and cannot safely make an
existing bitmap bit cover a smaller data range.
The llbitmap chunksize itself will not shrink when mddev->chunk_sectors
stays the same or grows. However, shrinking mddev->chunk_sectors can
shrink the effective data range covered by each bit for the RAID10
reshape geometry. Reject that reshape while llbitmap is active.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/raid10.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index 0a3cfdd3f5df..1242b8d3bb6b 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -4284,6 +4284,10 @@ static int raid10_check_reshape(struct mddev *mddev)
if (conf->geo.far_copies != 1 && !conf->geo.far_offset)
return -EINVAL;
+ if (mddev->bitmap_id == ID_LLBITMAP &&
+ mddev->new_chunk_sectors &&
+ mddev->new_chunk_sectors < mddev->chunk_sectors)
+ return -EOPNOTSUPP;
if (setup_geo(&geo, mddev, geo_start) != conf->copies)
/* mustn't change number of copies */
--
2.51.0
^ permalink raw reply related
* [PATCH v2 13/20] md/md-llbitmap: clamp state-machine walks to tracked bits
From: Yu Kuai @ 2026-06-24 6:42 UTC (permalink / raw)
To: Song Liu, Yu Kuai; +Cc: Li Nan, Xiao Ni, Su Yue, linux-raid, linux-kernel
In-Reply-To: <cover.1782282042.git.yukuai@kernel.org>
From: Yu Kuai <yukuai@fygo.io>
llbitmap_state_machine() can be called with an end bit beyond
llbitmap->chunks. In particular, llbitmap_cond_end_sync() passes
sector >> chunkshift, and sector can reach the tracked boundary
exactly.
Clamp the state-machine range to llbitmap->chunks so it cannot walk
past the tracked bitmap.
Signed-off-by: Yu Kuai <yukuai@fygo.io>
---
drivers/md/md-llbitmap.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-llbitmap.c b/drivers/md/md-llbitmap.c
index 00b77ecd600b..581ee9e4a346 100644
--- a/drivers/md/md-llbitmap.c
+++ b/drivers/md/md-llbitmap.c
@@ -983,7 +983,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;
while (start <= end) {
enum llbitmap_state c = llbitmap_read(llbitmap, start);
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox