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.
