Re: [PATCH 19/19] nvme-multipath: switch to use libmultipath

Nilay Shroff
2026-03-02T12:57:39Z

On 2/25/26 9:10 PM, John Garry wrote:
> void nvme_mpath_clear_ctrl_paths(struct nvme_ctrl *ctrl)
> @@ -277,30 +279,35 @@ void nvme_mpath_clear_ctrl_paths(struct nvme_ctrl *ctrl)
> srcu_idx = srcu_read_lock(&ctrl->srcu);
> list_for_each_entry_srcu(ns, &ctrl->namespaces, list,
> srcu_read_lock_held(&ctrl->srcu)) {
> + struct nvme_ns_head *head = ns->head;
> + struct mpath_disk *mpath_disk = head->mpath_disk;
> +
> + if (!mpath_disk)
> + continue;
> +
> nvme_mpath_clear_current_path(ns);
> - kblockd_schedule_work(&ns->head->requeue_work);
> + kblockd_schedule_work(&mpath_disk->mpath_head->requeue_work);
> }
> srcu_read_unlock(&ctrl->srcu, srcu_idx);
> }
>
> +static void nvme_mpath_revalidate_paths_cb(struct mpath_device *mpath_device,
> + sector_t capacity)
> +{
> + struct nvme_ns *ns = nvme_mpath_to_ns(mpath_device);
> +
> + if (capacity != get_capacity(ns->disk))
> + clear_bit(NVME_NS_READY, &ns->flags);
> +}
> +

I don't quite understand the intent of the above function.
Here I see that we compare mpath_disk capacity with per-path
disk. Do we really have sectors allocated for mpath_disk?

Overall, IMO abstracting out common multipath function into
a separate library is a good move. But then I just want to
understand layering here with libmultipath. Does it sit above
the driver or below? I see in some places we have back and forth
callbacks from driver to libmultipath and then back to the
driver, for instance:
nvme_mpath_add_disk => driver
-> mpath_device_set_live => libmultipath
-> mpath_head_add_cdev => libmultipath
-> nvme_mpath_add_cdev => driver

Does this intentional? Or am I missing overall picture...

Thanks,
--Nilay