Re: [PATCH v5 28/29] md/raid5: wire llbitmap reshape lifecycle

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Torn metadata update between llbitmap data and the array superblock during RAID5 reshape, leading to data corruption upon crash recovery.
--

--- Patch [28]: [PATCH v5 28/29] md/raid5: wire llbitmap reshape lifecycle ---
commit 3a12d425cf5a2752c68bb352670db1a3775e5849
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 67d56c92c8a44..5176de5b59568 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -6497,6 +6497,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: High]
Can this sequence cause a torn metadata update between the llbitmap data
and the array superblock during a reshape?

If a crash occurs in the window immediately after the bitmap pages are
synchronously flushed to disk here, but before the array superblock write
completes (via wait_event(mddev->sb_wait, mddev->sb_flags == 0) shortly
after), the system might reboot with an inconsistent bitmap state.

Since llbitmap relies entirely on the array's mddev->reshape_position
and doesn't track its own, could dirty bits be misread as clean due to
layout misalignment, potentially leading to degraded arrays skipping necessary
resyncs and causing data corruption upon recovery?

[ ... ]

> @@ -8732,10 +8752,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);
> +		}
> +

[Severity: High]
Does this have the same torn metadata update risk as above?

This flushes the reshaped bitmap layout to disk synchronously before the
array metadata is finalized by md_finish_reshape() shortly after. A crash
here seems like it would leave the bitmap and superblock out of sync in the
same way.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260802195038.164272-1-yukuai@kernel.org?part=28