Re: [PATCH AUTOSEL 6.18-5.10] md/raid5: let stripe batch bm_seq comparison wrap-safe

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Lockless Read-Modify-Write (RMW) race on batch_head->bm_seq could result in a stale bitmap sequence number.
--

commit ec929cd222791eadb056199cc433123ca41575a6
Author: Chen Cheng <chencheng@fnnas.com>

md/raid5: let stripe batch bm_seq comparison wrap-safe

This commit fixes a sequence number comparison bug in
stripe_add_to_batch_list() by changing a direct greater-than comparison to a
wrap-safe subtraction to ensure proper bitmap batch sequencing.

Link: https://patch.msgid.link/20260618025735.915113-1-chencheng@fnnas.com

> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -992,7 +992,7 @@ static void stripe_add_to_batch_list(struct r5conf *conf,
>  	if (test_and_clear_bit(STRIPE_BIT_DELAY, &sh->state)) {
>  		int seq = sh->bm_seq;
>  		if (test_bit(STRIPE_BIT_DELAY, &sh->batch_head->state) &&
> -		    sh->batch_head->bm_seq > seq)
> +		    sh->batch_head->bm_seq - seq > 0)
>  			seq = sh->batch_head->bm_seq;
>  		set_bit(STRIPE_BIT_DELAY, &sh->batch_head->state);
>  		sh->batch_head->bm_seq = seq;

[Severity: Critical]
This is a pre-existing issue, but could this lockless read-modify-write of
batch_head->bm_seq result in a stale bitmap sequence number?

During concurrent additions to a RAID5 stripe batch, threads handling disjoint
subordinate stripes (for example, sh1 and sh3) hold different stripe locks.
Because they do not contend for the same stripe locks, they can execute this
block concurrently on the same batch_head.

Could this concurrent access cause one thread to overwrite another thread's
newer bm_seq with an older one?

If a data race results in the batch head storing an older sequence number,
could the batch be written to disk before all required bitmap flushes have
completed? If a power failure occurs under these conditions, it appears the
dirty bits for some stripes in the batch might not be recorded in the bitmap,
which might lead to data corruption during array recovery.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-624-sashal@kernel.org?part=1