Re: [PATCH v5 05/27] libmultipath: Add support for mpath_device management

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `mpath_delete_device()` calls `mpath_synchronize()` without first removing the device from `current_path`, risking a use-after-free if callers rely on it for full synchronization.
--

--- Patch [5]: [PATCH v5 05/27] libmultipath: Add support for mpath_device management ---
commit 036ecbe8e851ac2a476516f8e8a72ff07e94750c
Author: John Garry <[email protected]>

libmultipath: Add support for mpath_device management

This commit adds support to add or remove an mpath_device as a path.
It introduces equivalents to NVMe mpath functions like clearing, adding,
and removing sysfs links, as well as revalidating paths.

> diff --git a/lib/multipath.c b/lib/multipath.c
> index db5f83ebe5d7f..f70049b6cede9 100644
> --- a/lib/multipath.c
> +++ b/lib/multipath.c

[ ... ]

> +bool mpath_delete_device(struct mpath_device *mpath_device)
> +{
> +	bool empty;
> +
> +	mutex_lock(&mpath_device->mpath_head->lock);
> +	list_del_rcu(&mpath_device->siblings);
> +	empty = list_empty(&mpath_device->mpath_head->dev_list);
> +	mutex_unlock(&mpath_device->mpath_head->lock);
> +
> +	mpath_synchronize(mpath_device->mpath_head);

[Severity: Medium]
Does this code leave the device accessible to new RCU readers via the
current_path array?

By calling mpath_synchronize() here without first removing the device from
current_path (for example, by calling mpath_clear_current_path() before
synchronization), new RCU readers could still find and access the device.
If callers assume mpath_delete_device() provides full synchronization and
subsequently free the device, could this lead to a use-after-free?

> +
> +	return empty;
> +}

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