Re: [PATCH v2 4/8] md: defer the io_opt update out of the sync thread

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ABBA/4-thread deadlock in __md_stop() when synchronously flushing io_opt_work while holding reconfig_mutex.
--

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

md: defer the io_opt update out of the sync thread

This patch defers the mddev_update_io_opt() call from the sync thread into a
work item to avoid hanging a finishing reshape when taking q->limits_lock.
The __md_stop() function is updated to flush this work item during array
suspension.

> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 3067ea05ba276..87e17ba86d93a 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c

[ ... ]

> @@ -7139,6 +7172,8 @@ static void __md_stop(struct mddev *mddev)
>  {
>  	struct md_personality *pers = mddev->pers;
>  
> +	/* the deferred io_opt update suspends the array, so let it finish */
> +	flush_work(&mddev->io_opt_work);

[Severity: High]
Can this flush_work() call lead to a deadlock when the array is stopped while
I/O is active?

The array stop sequence holds reconfig_mutex while calling __md_stop(), which
blocks here waiting for md_io_opt_work() to complete.

Meanwhile, md_io_opt_work() calls mddev_suspend(), which blocks indefinitely
waiting for the active_io refcount to drop to zero:

drivers/md/md.c:md_io_opt_work() {
    ...
	lim = queue_limits_start_update(q);
	if (mddev_suspend(mddev, false) < 0) {
    ...
}

However, a concurrent write I/O can increment active_io and then block in
md_write_start() waiting for the MD management thread to clear
MD_SB_CHANGE_PENDING:

drivers/md/md.c:md_write_start() {
    ...
	wait_event(mddev->sb_wait,
		   !test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags));
    ...
}

The MD management thread cannot clear this flag because it wakes up to update
the superblock but fails to acquire reconfig_mutex:

drivers/md/md.c:md_check_recovery() {
    ...
	if (mddev_trylock(mddev)) {
    ...
}

Since the array stop sequence holds reconfig_mutex, this creates a 4-thread
circular dependency:

1. array stop thread waits for md_io_opt_work() to complete
2. md_io_opt_work() thread waits for active_io to reach zero
3. write I/O holding active_io waits for MD thread to clear
   MD_SB_CHANGE_PENDING
4. MD thread waits for array stop thread to release reconfig_mutex

Does the flush_work() call need to be moved outside the section holding
reconfig_mutex, or could the workqueue be drained earlier?

>  	mddev_detach(mddev);
>  	md_bitmap_destroy(mddev);
>  	spin_lock(&mddev->lock);

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