Re: [PATCH v3 18/21] md/raid5: add exact old and new llbitmap mapping helpers

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Integer overflow in `raid5_bitmap_sector` leading to silent data corruption on 32-bit architectures during reshape.
--

--- Patch [18]: [PATCH v3 18/21] md/raid5: add exact old and new llbitmap mapping helpers ---
commit c431d4e1772c99b9b41c44d5e8369daa1885b7eb
Author: Yu Kuai <[email protected]>

md/raid5: add exact old and new llbitmap mapping helpers

This commit refactors the bitmap sector calculations in RAID5 to export
exact old and new mappings, along with sync and array sizes, to support
reshape-aware bitmap users.

> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 35910bc6683bf..8b28afa538e2b 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c

[ ... ]

> @@ -5992,7 +6001,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: Critical]
This is a pre-existing issue, but does this calculation overflow on 32-bit
architectures during a large array reshape?

When an IO is issued ahead of the reshape progress, raid5_bitmap_sector()
merges the old and new physical mappings into a single range. For very large
arrays, the distance between the old and new physical device offsets can
easily exceed 2TB.

Because the sectors parameter is an unsigned long pointer, which is 32-bit
on 32-bit systems, subtracting these 64-bit sector_t endpoints produces a
64-bit difference that is silently truncated when assigned to *sectors.

If a crash occurs during this reshape, wouldn't the bitmap layer record only
a truncated fraction of the required range, causing the array to fail to
resync the full region and potentially resulting in silent data corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=18