From: Nilay Shroff <nilay@linux.ibm.com>
To: wenxiong@linux.ibm.com, linux-nvme@lists.infradead.org,
kbusch@kernel.org
Cc: gjoyce@linux.ibm.com, wenxiong@us.ibm.com
Subject: Re: [PATCH V2] nvme: Add module reference counting for multipath devices
Date: Wed, 26 Aug 2026 18:10:09 +0530 [thread overview]
Message-ID: <d3cb6438-f1b6-4b46-9f96-56819052bc02@linux.ibm.com> (raw)
In-Reply-To: <20260812223206.720363-1-wenxiong@linux.ibm.com>
On 8/13/26 4:02 AM, wenxiong@linux.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.ibm.com>
>
> Add proper module reference counting to prevent premature unloading of
> NVMe transport modules while multipath namespaces are still active.
>
> When a namespace is added to a multipath device via nvme_mpath_add_disk(),
> the underlying transport module (PCIe, FC, RDMA, TCP, etc.) must remain
> loaded as long as the multipath device references that namespace. Without
> proper reference counting, the transport module could be unloaded while
> the multipath device is still using resources from that module, leading
> to the potential system crashes.
>
> This ensures the transport module remains loaded for the entire lifetime
> of the multipath namespace association.
>
> Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>
> ---
> drivers/nvme/host/multipath.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
> index 9b9a657fa330..707b8f95727d 100644
> --- a/drivers/nvme/host/multipath.c
> +++ b/drivers/nvme/host/multipath.c
> @@ -1348,6 +1348,8 @@ void nvme_mpath_remove_sysfs_link(struct nvme_ns *ns)
> sysfs_remove_link_from_group(kobj, nvme_ns_mpath_attr_group.name,
> dev_name(target));
> clear_bit(NVME_NS_SYSFS_ATTR_LINK, &ns->flags);
> +
> + module_put(ns->ctrl->ops->module);
> }
>
> void nvme_mpath_add_disk(struct nvme_ns *ns, __le32 anagrpid)
> @@ -1379,6 +1381,9 @@ void nvme_mpath_add_disk(struct nvme_ns *ns, __le32 anagrpid)
> if (blk_queue_is_zoned(ns->queue) && ns->head->disk)
> ns->head->disk->nr_zones = ns->disk->nr_zones;
> #endif
> + if (!try_module_get(ns->ctrl->ops->module))
> + dev_err(disk_to_dev(ns->disk),
> + "Failed to get module reference\n");
> }
>
> void nvme_mpath_remove_disk(struct nvme_ns_head *head)
I know I am late to the party here, but I don't think adding the
module refcounting in nvme_mpath_{add|remove}_sysfs_link() is the
right approach. That would increment the transport module reference
for every namespace/path, which means the transport module could
not be unloaded until all namespaces using it are deleted, even
when none of those namespaces are actually in use. So for instance,
with this change now, I can't rmmod nvme.ko until I delete
all namespaces/paths created under PCIe nvme subsystem, even though
no one is using the namespace/path under that subsystem.
Instead, I think the module reference should track the lifetime of an
active user of the multipath namespace. When the namespace is in use,
the corresponding transport module(s) need to remain loaded and once
the namespace is no longer in use, those references should be released.
Looking at the current code, nvme_ns_head_{open|release}() seems to be
a more appropriate place for this. When a multipath namespace is opened,
nvme_ns_head_open() could take the required transport module references,
and nvme_ns_head_release() could drop them when the last user releases
the namespace.
Also, since a multipath head can have paths through different transports
, we should not take a reference only to the transport of one namespace/path
found through nvme_find_path(), as was done in v1. Instead, when opening the
head, take a module reference iterating through each controller reachable
from the corresponding NVMe subsystem. This ensures that every transport
that can service I/O for the active multipath namespace remains loaded for
the duration of its use.
Thanks,
--Nilay
next prev parent reply other threads:[~2026-08-26 12:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 22:32 [PATCH V2] nvme: Add module reference counting for multipath devices wenxiong
2026-08-20 4:19 ` Nares Bannoth
2026-08-23 0:20 ` Sagi Grimberg
2026-08-23 0:46 ` Sagi Grimberg
2026-08-24 20:23 ` Wen Xiong
2026-08-25 19:11 ` Wen Xiong
2026-08-30 21:46 ` Sagi Grimberg
2026-08-26 12:40 ` Nilay Shroff [this message]
2026-08-26 14:23 ` Keith Busch
2026-08-26 16:18 ` Wen Xiong
2026-08-26 16:36 ` Keith Busch
2026-08-27 13:21 ` Nilay Shroff
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=d3cb6438-f1b6-4b46-9f96-56819052bc02@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=gjoyce@linux.ibm.com \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=wenxiong@linux.ibm.com \
--cc=wenxiong@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox