Re: [PATCH v8 06/27] libmultipath: Add delayed removal support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Disabling delayed removal via sysfs leaves pending IOs stranded in the requeue list and fails to cancel the teardown timer.
--

commit 13530eba33df6a0206410ca4e486f37c5aabe865
Author: John Garry <john.garry@linux.dev>

libmultipath: Add delayed removal support

This commit adds support for delayed removal of multipath devices, similar
to NVMe. It introduces a sysfs attribute to configure a timeout window
during which I/O is requeued instead of failed when no paths are available.

> diff --git a/lib/multipath.c b/lib/multipath.c
> index f24086a6e3012..9fcf0b743f0e1 100644
> --- a/lib/multipath.c
> +++ b/lib/multipath.c

[ ... ]

> +ssize_t mpath_delayed_removal_secs_store(struct mpath_head *mpath_head,
> +			const char *buf, size_t count)
> +{
> +	unsigned int sec;
> +	ssize_t ret;
> +
> +	ret = kstrtouint(buf, 0, &sec);
> +	if (ret < 0)
> +		return ret;
> +
> +	mutex_lock(&mpath_head->lock);
> +	mpath_head->delayed_removal_secs = sec;
> +	if (sec)
> +		set_bit(MPATH_HEAD_QUEUE_IF_NO_PATH, &mpath_head->flags);
> +	else
> +		clear_bit(MPATH_HEAD_QUEUE_IF_NO_PATH, &mpath_head->flags);
> +	mutex_unlock(&mpath_head->lock);
> +
> +	/*
> +	 * Ensure that update to MPATH_HEAD_QUEUE_IF_NO_PATH is seen
> +	 * by its reader.
> +	 */
> +	mpath_synchronize(mpath_head);
> +
> +	return count;

[Severity: High]
Does disabling delayed removal here leave pending I/Os stranded in the requeue
list and fail to cancel the teardown timer?

If all paths go offline while delayed_removal_secs is non-zero, new I/Os
are queued in requeue_list. If an administrator subsequently writes 0 to
this sysfs attribute to disable delayed removal,
mpath_delayed_removal_secs_store() in lib/multipath.c clears the
MPATH_HEAD_QUEUE_IF_NO_PATH flag but does not call
mpath_schedule_requeue_work() to flush existing stranded I/Os.

Additionally, it doesn't appear to cancel the pending remove_work timer,
which might cause the device teardown to be arbitrarily delayed by the old
timeout value rather than executing immediately upon user reconfiguration.
Could these unhandled I/Os hang indefinitely?

> +}
> +EXPORT_SYMBOL_GPL(mpath_delayed_removal_secs_store);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907105021.1763236-1-john.g.garry@oracle.com?part=6