[PATCH 02/13] libmultipath: Add basic gendisk support

Nilay Shroff nilay at linux.ibm.com
Mon Mar 2 04:31:05 PST 2026


On 2/25/26 9:02 PM, John Garry wrote:
> Add support to allocate and free a multipath gendisk.
> 
> NVMe has almost like-for-like equivalents here:
> - mpath_alloc_head_disk() -> nvme_mpath_alloc_disk()
> - multipath_partition_scan_work() -> nvme_partition_scan_work()
> - mpath_remove_disk() -> nvme_remove_head()
> - mpath_device_set_live() -> nvme_mpath_set_live()
> 
> struct mpath_head_template is introduced as a method for drivers to
> provide custom multipath functionality.
> 
> Signed-off-by: John Garry <john.g.garry at oracle.com>
> ---
>   include/linux/multipath.h |  41 ++++++++++++
>   lib/multipath.c           | 129 ++++++++++++++++++++++++++++++++++++++
>   2 files changed, 170 insertions(+)
> 
> diff --git a/include/linux/multipath.h b/include/linux/multipath.h
> index 18cd133b7ca21..be9dd9fb83345 100644
> --- a/include/linux/multipath.h
> +++ b/include/linux/multipath.h
> @@ -5,11 +5,28 @@
>   #include <linux/blkdev.h>
>   #include <linux/srcu.h>
>   
> +extern const struct block_device_operations mpath_ops;
> +
> +struct mpath_disk {
> +	struct gendisk		*disk;
> +	struct kref		ref;
> +	struct work_struct	partition_scan_work;
> +	struct mutex		lock;
> +	struct mpath_head	*mpath_head;
> +	struct device		*parent;
> +};
> +
>   struct mpath_device {
>   	struct list_head	siblings;
>   	struct gendisk		*disk;
>   };
>   
> +struct mpath_head_template {
> +	const struct attribute_group **device_groups;
> +};
> +
> +#define MPATH_HEAD_DISK_LIVE 			0
> +
>   struct mpath_head {
>   	struct srcu_struct	srcu;
>   	struct list_head	dev_list;	/* list of all mpath_devs */
> @@ -17,12 +34,36 @@ struct mpath_head {
>   
>   	struct kref		ref;
>   
> +	unsigned long		flags;
>   	struct mpath_device __rcu 		*current_path[MAX_NUMNODES];
> +	const struct mpath_head_template	*mpdt;
>   	void			*drvdata;
>   };
>   
Not sure why we don't have back reference to struct mpath_disk
from struct mpath_head here. Does it make sense to have this?


> +static inline struct mpath_disk *mpath_bd_device_to_disk(struct device *dev)
> +{
> +	return dev_get_drvdata(dev);
> +}
> +
> +static inline struct mpath_disk *mpath_gendisk_to_disk(struct gendisk *disk)
> +{
> +	return mpath_bd_device_to_disk(disk_to_dev(disk));
> +}
> +
>   int mpath_get_head(struct mpath_head *mpath_head);
>   void mpath_put_head(struct mpath_head *mpath_head);
>   struct mpath_head *mpath_alloc_head(void);
> +void mpath_put_disk(struct mpath_disk *mpath_disk);
> +void mpath_remove_disk(struct mpath_disk *mpath_disk);
> +void mpath_unregister_disk(struct mpath_disk *mpath_disk);
> +struct mpath_disk *mpath_alloc_head_disk(struct queue_limits *lim,
> +			int numa_node);
> +void mpath_device_set_live(struct mpath_disk *mpath_disk,
> +			struct mpath_device *mpath_device);
> +void mpath_unregister_disk(struct mpath_disk *mpath_disk);
>   
> +static inline bool is_mpath_head(struct gendisk *disk)
> +{
> +	return disk->fops == &mpath_ops;
> +}
>   #endif // _LIBMULTIPATH_H
> diff --git a/lib/multipath.c b/lib/multipath.c
> index 15c495675d729..88efb0ae16acb 100644
> --- a/lib/multipath.c
> +++ b/lib/multipath.c
> @@ -32,6 +32,135 @@ void mpath_put_head(struct mpath_head *mpath_head)
>   }
>   EXPORT_SYMBOL_GPL(mpath_put_head);
>   
> +static void mpath_free_disk(struct kref *ref)
> +{
> +	struct mpath_disk *mpath_disk =
> +		container_of(ref, struct mpath_disk, ref);
> +	struct mpath_head *mpath_head = mpath_disk->mpath_head;
> +
> +	put_disk(mpath_disk->disk);
> +	mpath_put_head(mpath_head);
> +	kfree(mpath_disk);
> +}
> +

The mpath_alloc_head_disk() doesn't get a reference to the
mpath_head object but here while freeing mpath_disk we put
the reference to mpath_head. Would that create a reference
imbalance? Yes we got a reference to mpath_head while
allocating it but then these are two (alloc mpath_disk and
alloc mpath_head) disjoint operations. In that case, can't
we have both mpath_disk and mpath_head allocated under one
libmultipath API?

Thanks,
--Nilay





More information about the Linux-nvme mailing list