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
