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

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 superbloc=
k 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 <[email protected]>

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 *mdde=
v, sector_t sector_nr, int *sk
>  			   || test_bit(MD_RECOVERY_INTR, &mddev->recovery));
>  		if (atomic_read(&conf->reshape_stripes) !=3D 0)
>  			return 0;
> +		if (md_bitmap_enabled(mddev, false) &&
> +		    mddev->bitmap_ops->reshape_mark &&
> +		    conf->reshape_safe !=3D 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 =3D=3D 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 necess=
ary
resyncs and causing data corruption upon recovery?

[ ... ]

> @@ -8732,10 +8752,19 @@ static int raid5_start_reshape(struct mddev *mdde=
v)
>   */
>  static void end_reshape(struct r5conf *conf)
>  {
> +	struct mddev *mddev =3D conf->mddev;
> =20
>  	if (!test_bit(MD_RECOVERY_INTR, &conf->mddev->recovery)) {
>  		struct md_rdev *rdev;
> =20
> +		if (md_bitmap_enabled(mddev, false) &&
> +		    mddev->bitmap_ops->reshape_mark &&
> +		    conf->reshape_safe !=3D 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.

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802195038.1642=
[email protected]?part=3D28