From: Nilay Shroff <nilay@linux.ibm.com>
To: Keith Busch <kbusch@kernel.org>, Wen Xiong <wenxiong@linux.ibm.com>
Cc: linux-nvme@lists.infradead.org, gjoyce@linux.ibm.com,
wenxiong@us.ibm.com
Subject: Re: [PATCH V2] nvme: Add module reference counting for multipath devices
Date: Thu, 27 Aug 2026 18:51:17 +0530 [thread overview]
Message-ID: <e09f539f-a6f8-40ec-aac6-0722289e5591@linux.ibm.com> (raw)
In-Reply-To: <ao8WB4Ywz_akBEdR@kbusch-mbp>
On 8/26/26 10:06 PM, Keith Busch wrote:
> On Wed, Aug 26, 2026 at 11:18:16AM -0500, Wen Xiong wrote:
>> On 2026-08-26 07:40, Nilay Shroff wrote:
>>
>>> 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.
>>>
>> I will look into iterating though each controller/each namespace from nvme
>> subsystem.
>
> This is not viable. You can add and remove paths to a namespace at any
> time such that the transports counted on open are not the namespace's
> transports on close.
Yes correct, and I think we need some additional change in the code to
handle this gracefully. I though about it have some initial idea to
address this:
1. Add nr_openers to struct nvme_ns_head.
2. When the ns head is opened, iterate through each namespace associated
with the head and increment the reference count of its underlying
transport module. Then increment nr_openers.
3. If a new ns/path is added while the head is open, check nr_openers and,
if it is non-zero, increment the reference count of the corresponding
transport module nr_openers times.
4. If an existing ns/path is removed while the head is open, check nr_openers
and decrement the reference count of the corresponding transport module
nr_openers times.
5. When the ns head is closed, iterate through the namespaces associated
with the head and decrement the reference count of each underlying
transport module. Then decrement nr_openers.
The above operations are serialized by subsys->lock, so nr_openers serves
as the number of users that have actually opened the head node.
For example, suppose we have a shared namespace reachable through
TCP and RDMA paths:
1. User opens the head node:
head->nr_openers = 1; tcp_module_ref_count = 1; rdma_module_ref_count = 1
2. The RDMA path is removed:
head->nr_openers = 1; tcp_module_ref_count = 1; rdma_module_ref_count = 0
3. User closes the head node:
head->nr_openers = 0; tcp_module_ref_count = 0; rdma_module_ref_count = 0
Another example with multiple openers:
1. User A opens the head node:
head->nr_openers = 1; tcp_module_ref_count = 1; rdma_module_ref_count = 1
2. A new TCP path is added and linked to the head:
head->nr_openers = 1; tcp_module_ref_count = 2; rdma_module_ref_count = 1
3. User B opens the head node:
head->nr_openers = 2; tcp_module_ref_count = 4; rdma_module_ref_count = 2
4. User A closes the head node:
head->nr_openers = 1; tcp_module_ref_count = 2; rdma_module_ref_count = 1
5. The RDMA path is removed:
head->nr_openers = 1; tcp_module_ref_count = 2; rdma_module_ref_count = 0
6. User B closes the head node:
head->nr_openers = 0; tcp_module_ref_count = 0; rdma_module_ref_count = 0
This way, the transport module references track the actual number of openers
and the set of paths associated with the head, even when paths are dynamically
added or removed while the head remains open.
Thanks,
--Nilay
prev parent reply other threads:[~2026-08-27 13:21 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
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 [this message]
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=e09f539f-a6f8-40ec-aac6-0722289e5591@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