All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: John Garry <john.g.garry@oracle.com>,
	hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com,
	martin.petersen@oracle.com,
	james.bottomley@hansenpartnership.com, hare@suse.com
Cc: jmeneghi@redhat.com, linux-nvme@lists.infradead.org,
	linux-scsi@vger.kernel.org, michael.christie@oracle.com,
	snitzer@kernel.org, bmarzins@redhat.com,
	dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/13] libmultipath: Add basic gendisk support
Date: Mon, 2 Mar 2026 18:01:05 +0530	[thread overview]
Message-ID: <98aa0bac-bf62-4e7e-b7c6-d2547ab34ef7@linux.ibm.com> (raw)
In-Reply-To: <20260225153225.1031169-3-john.g.garry@oracle.com>

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



  parent reply	other threads:[~2026-03-02 12:31 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25 15:32 [PATCH 00/13] libmultipath: a generic multipath lib for block drivers John Garry
2026-02-25 15:32 ` [PATCH 01/13] libmultipath: Add initial framework John Garry
2026-03-02 12:08   ` Nilay Shroff
2026-03-02 12:21     ` John Garry
2026-02-25 15:32 ` [PATCH 02/13] libmultipath: Add basic gendisk support John Garry
2026-02-26  2:16   ` Benjamin Marzinski
2026-02-26  9:04     ` John Garry
2026-03-02 12:31   ` Nilay Shroff [this message]
2026-03-02 15:39     ` John Garry
2026-03-03 12:39       ` Nilay Shroff
2026-03-03 12:59         ` John Garry
2026-03-03 12:13   ` Markus Elfring
2026-02-25 15:32 ` [PATCH 03/13] libmultipath: Add path selection support John Garry
2026-02-26  3:37   ` Benjamin Marzinski
2026-02-26  9:26     ` John Garry
2026-03-02 12:36   ` Nilay Shroff
2026-03-02 15:11     ` John Garry
2026-03-03 11:01       ` Nilay Shroff
2026-03-03 12:41         ` John Garry
2026-03-04 10:26           ` Nilay Shroff
2026-03-04 11:09             ` John Garry
2026-04-14 10:03             ` John Garry
2026-04-14 11:43               ` Nilay Shroff
2026-04-14 13:10                 ` John Garry
2026-03-04 13:10   ` Nilay Shroff
2026-03-04 14:38     ` John Garry
2026-02-25 15:32 ` [PATCH 04/13] libmultipath: Add bio handling John Garry
2026-03-02 12:39   ` Nilay Shroff
2026-03-02 15:52     ` John Garry
2026-03-03 14:00       ` Nilay Shroff
2026-02-25 15:32 ` [PATCH 05/13] libmultipath: Add support for mpath_device management John Garry
2026-02-25 15:32 ` [PATCH 06/13] libmultipath: Add cdev support John Garry
2026-02-25 15:32 ` [PATCH 07/13] libmultipath: Add delayed removal support John Garry
2026-03-02 12:41   ` Nilay Shroff
2026-03-02 15:54     ` John Garry
2026-04-08 11:28     ` John Garry
2026-04-08 15:41       ` Hannes Reinecke
2026-04-08 16:28         ` John Garry
2026-04-09  6:37           ` Nilay Shroff
2026-04-09 13:00             ` John Garry
2026-04-10  7:06               ` Nilay Shroff
2026-04-10  8:55                 ` John Garry
2026-04-10  9:09                   ` Nilay Shroff
2026-04-10  9:49                     ` John Garry
2026-04-10 10:51                       ` Nilay Shroff
2026-04-10 11:49                         ` John Garry
2026-02-25 15:32 ` [PATCH 08/13] libmultipath: Add sysfs helpers John Garry
2026-02-27 19:05   ` Benjamin Marzinski
2026-03-02 11:11     ` John Garry
2026-02-25 15:32 ` [PATCH 09/13] libmultipath: Add PR support John Garry
2026-02-25 15:49   ` Keith Busch
2026-02-25 16:52     ` John Garry
2026-02-27 18:12     ` Benjamin Marzinski
2026-03-02 10:45       ` John Garry
2026-02-25 15:32 ` [PATCH 10/13] libmultipath: Add mpath_bdev_report_zones() John Garry
2026-02-25 15:32 ` [PATCH 11/13] libmultipath: Add support for block device IOCTL John Garry
2026-02-27 19:52   ` Benjamin Marzinski
2026-03-02 11:19     ` John Garry
2026-04-09 15:20     ` John Garry
2026-02-25 15:32 ` [PATCH 12/13] libmultipath: Add mpath_bdev_getgeo() John Garry
2026-02-25 15:32 ` [PATCH 13/13] libmultipath: Add mpath_bdev_get_unique_id() John Garry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98aa0bac-bf62-4e7e-b7c6-d2547ab34ef7@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@fb.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jmeneghi@redhat.com \
    --cc=john.g.garry@oracle.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=sagi@grimberg.me \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.