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

[John Garry]

On 02/03/2026 12:57, Nilay Shroff wrote:
> 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.

This specifically is a callback for when the NVMe driver calls into 
libmultipath. It could also be supplied in the function template.

If you check mainline nvme_mpath_revalidate_paths(), it iterates the 
paths, and for each part checks capacity and unsets NVME_NS_READY if set.

Now libmultipath manages the paths, so we provide an API for the driver 
to call into the iterate the paths to support 
nvme_mpath_revalidate_paths(). Since we are doing something 
nvme-specific in nvme_mpath_revalidate_paths(), we need the driver to 
provide a CB to do this driver-specific functionality.

> Here I see that we compare mpath_disk capacity with per-path
> disk. Do we really have sectors allocated for mpath_disk?

mpath_disk manages the multipath gendisk - it is no longer in 
nvme_ns_head.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 would say neither - or it sits above the driver, if anything. It is 
just a library for managing multipathed devices.

> 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...

Something like nvme_mpath_add_cdev is a callback supplied for 
libmultipath to do some driver-specific action. About 
nvme_mpath_add_cdev(), I think that this can be pushed into 
libmultipath. The only NVMe specific thing it does is the device naming 
- so a method for the nvme driver to supply that is required.

Thanks for checking all this.