All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: wenxiong@linux.ibm.com, hch@lst.de
Cc: kbusch@kernel.org, linux-nvme@lists.infradead.org, wenxiong@us.ibm.com
Subject: Re: [PATCH 1/1] nvme-multipath: show wrong nvme ns after dlpar a nvme device
Date: Sat, 28 May 2022 14:16:04 +0200	[thread overview]
Message-ID: <04624b93-e03c-4fd4-8201-031b1c6bb04e@suse.de> (raw)
In-Reply-To: <1653666577-3733-1-git-send-email-wenxiong@linux.ibm.com>

On 5/27/22 17:49, wenxiong@linux.ibm.com wrote:
> From: Wen Xiong <wenxiong@linux.ibm.com>
> 
> If we have an active partition/namespace on nvme device, nvme device driver
> won’t release these controller IDs/Namespaces IDs when dlpar remove.
> So we got the wrong nvme devices names if nvme device driver still use old
> subsystem id as controller id when dlpar add it back. We expect to see new
> nvme devices with new controller IDs/Namespace IDs.
> 
> For example, we have a nvme U2 device with 4 namespaces in linux,
> 
> After system boots up,
> Controller id:  0
> Subsystem id:   0
> namespaces ids: 1, 2, 3 and 4
> nvme devices  : nvme0n1, nvme0n2, nvme0n3 and nvme0n4
> 
> Dlpar remove with active partitions on nvme0n1,
> Controller id :   ID=0 still hold reference, ID=0 won’t be removed,  but /dev/nvme0 not exists anymore
> Subsystem id :    0(nvme-subsys0 still exist in nvme list-subsys)
> Namespace ids:    ID=1 still hold reference, ID=1 won’t be removed, but /dev/nvme0n1 not exists anymore
> Nvme devices:  all nvme devices are gone in /dev
> 
> Dlpar Add back
> Controller id:  1
> Subsystem id :  0 still use old controller id=0
> namespaces ids: 2, 3, 4 and 5
> nvme devices:   We saw "nvme0n2, nvme0n3, nvme0n4, nvme0n5" in /dev
>                  /dev/nvme0 not exist anymore,
>                  We expect to see: nvme1n2, nvme1n3, nvme1n4 and nvme1n5
> 
> The patch fixes the issue.
> 
> Signed-off-by: Wen Xiong <wenxiong@linux.ibm.com>
> ---
>   drivers/nvme/host/multipath.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
> index d464fdf978fb..945974ceef3c 100644
> --- a/drivers/nvme/host/multipath.c
> +++ b/drivers/nvme/host/multipath.c
> @@ -495,7 +495,7 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl, struct nvme_ns_head *head)
>   	head->disk->fops = &nvme_ns_head_ops;
>   	head->disk->private_data = head;
>   	sprintf(head->disk->disk_name, "nvme%dn%d",
> -			ctrl->subsys->instance, head->instance);
> +			ctrl->instance, head->instance);
>   
>   	blk_queue_flag_set(QUEUE_FLAG_NONROT, head->disk->queue);
>   	blk_queue_flag_set(QUEUE_FLAG_NOWAIT, head->disk->queue);

No, this is wrong.
The nvme subsystem is an internal construct within the linux subsystem, 
and the lifetime of that is determined by the lifetime of the associated 
controllers and namespaces.
So as long as a controller object (!) or namespace object exists which 
refer to the subsystem NQN, that subsystem object will exist.
When a controller is removed/detached by the dlpar the device nodes will 
be removed from the system, and the controller object itself will be 
freed/removed after the last reference drops. And only then will the 
reference to the subsystem be dropped, causing the subsystem object to 
be removed.
So if a new controller referring to the same subsystem NQN is connected 
while the subsystem object is still present it will naturally select 
that subsystem.

Everything is working as designed.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman


      parent reply	other threads:[~2022-05-28 12:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27 15:49 [PATCH 1/1] nvme-multipath: show wrong nvme ns after dlpar a nvme device wenxiong
2022-05-27 20:52 ` Keith Busch
2022-05-28  5:17 ` Christoph Hellwig
2022-05-28 12:16 ` Hannes Reinecke [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=04624b93-e03c-4fd4-8201-031b1c6bb04e@suse.de \
    --to=hare@suse.de \
    --cc=hch@lst.de \
    --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 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.