Re: [PATCH v2 1/8] md: pass a queue_limits down to ->hot_add_disk()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] raid1_add_disk fails to stack limits or validate compatibility for replacement disks.
--

commit d7876b523180e9507873b141ec81e8cdf84d9929
Author: Jack Wang <jinpu.wang@cloud.ionos.com>

md: pass a queue_limits down to ->hot_add_disk()

This commit updates the md hot-add disk paths to accept a queue_limits
argument. This allows callers to manage the limits lock explicitly when
adding a disk, preventing potential deadlocks.

[ ... ]
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1923,7 +1924,12 @@ static int raid1_add_disk(struct mddev *mddev, struct md_rdev *rdev)
>  	for (mirror = first; mirror <= last; mirror++) {
>  		p = conf->mirrors + mirror;
>  		if (!p->rdev) {
> -			err = mddev_stack_new_rdev(mddev, rdev);
> +			if (lim == MDDEV_STACK_SKIP)
> +				err = 0;
> +			else if (lim)
> +				err = mddev_stack_rdev_into(mddev, rdev, lim);
> +			else
> +				err = mddev_stack_new_rdev(mddev, rdev);
>  			if (err)
>  				return err;

[ ... ]

> 		if (test_bit(WantReplacement, &p->rdev->flags) &&
> 		    p[conf->raid_disks].rdev == NULL && repl_slot < 0)
> 			repl_slot = mirror;
> 	}
> 
> 	if (err && repl_slot >= 0) {
> 		/* Add this device as a replacement */
> 		clear_bit(In_sync, &rdev->flags);
> 		set_bit(Replacement, &rdev->flags);
> 		raid1_add_conf(conf, rdev, repl_slot, true);
> 		err = 0;
> 		conf->fullsync = 1;
> 	}

[Severity: High]
This is a pre-existing issue, but does this replacement path in
raid1_add_disk() omit queue limits validation?

Unlike the primary hot-add path modified above, the fallback block for
configuring replacement disks skips the queue limits stacking entirely.
If a replacement disk is hot-added with incompatible features, such as
a larger logical block size or an unsupported integrity profile, it
appears the array will accept the disk without validation.

Could this allow the queue limits API contract to be bypassed,
potentially leading to misaligned I/Os being sent to the underlying
block device and resulting in I/O errors or data corruption during array
reconstruction?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910081114.1605746-1-jinpu.wang@ionos.com?part=1