Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Leng <lengchao@huawei.com>
To: Hannes Reinecke <hare@suse.de>, Daniel Wagner <dwagner@suse.de>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
	Jens Axboe <axboe@fb.com>, Keith Busch <kbusch@kernel.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v2] nvme-multipath: Early exit if no path is available
Date: Fri, 29 Jan 2021 09:18:10 +0800	[thread overview]
Message-ID: <c91cb4df-6736-bc0f-9d33-ecc3e2f4f510@huawei.com> (raw)
In-Reply-To: <8704038d-0b71-5c9c-2d2b-a9ff2166dbe4@suse.de>



On 2021/1/28 17:23, Hannes Reinecke wrote:
> On 1/28/21 10:18 AM, Chao Leng wrote:
>>
>>
>> On 2021/1/28 15:58, Daniel Wagner wrote:
>>> On Thu, Jan 28, 2021 at 09:31:30AM +0800, Chao Leng wrote:
>>>>> --- a/drivers/nvme/host/multipath.c
>>>>> +++ b/drivers/nvme/host/multipath.c
>>>>> @@ -221,7 +221,7 @@ static struct nvme_ns *nvme_round_robin_path(struct nvme_ns_head *head,
>>>>>        }
>>>>>        for (ns = nvme_next_ns(head, old);
>>>>> -         ns != old;
>>>>> +         ns && ns != old;
>>>> nvme_round_robin_path just be called when !"old".
>>>> nvme_next_ns should not return NULL when !"old".
>>>> It seems unnecessary to add checking "ns".
>>>
>>> The problem is when we enter nvme_round_robin_path() and there is no
>>> path available. In this case the initialization ns = nvme_next_ns(head,
>>> old) could return a NULL pointer."old" should not be NULL, so there is at least one path that is "old".
>> It is impossible to return NULL for nvme_next_ns(head, old).
> 
> No. list_next_or_null_rcu()/list_first_or_null_rcu() will return NULL when then end of the list is reached.
Although list_next_or_null_rcu()/list_first_or_null_rcu() may return
NULL, but nvme_next_ns(head, old) assume that the "old" is in the "head",
so nvme_next_ns(head, old) should not return NULL. If the "old" is not
in the "head", nvme_next_ns(head, old) will run abnormal.
So there is other bug which cause nvme_next_ns(head, old).

I review the code about head->list and head->current_path, I find 2 bugs
may cause nvme_next_ns(head, old) abnormal:
First, I already send the patch. see:
https://lore.kernel.org/linux-nvme/20210128033351.22116-1-lengchao@huawei.com/
Second, in nvme_ns_remove, list_del_rcu is before
nvme_mpath_clear_current_path. This may cause "old" is deleted from the
"head", but still use "old". I'm not sure there's any other
consideration here, I will check it and try to fix it.
> 
> Cheers,
> 
> Hannes

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2021-01-29  1:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 10:30 [PATCH v2] nvme-multipath: Early exit if no path is available Daniel Wagner
2021-01-27 10:34 ` Hannes Reinecke
2021-01-27 16:49 ` Christoph Hellwig
2021-01-28  1:31 ` Chao Leng
2021-01-28  7:58   ` Daniel Wagner
2021-01-28  9:18     ` Chao Leng
2021-01-28  9:23       ` Hannes Reinecke
2021-01-29  1:18         ` Chao Leng [this message]
2021-01-28  9:40       ` Daniel Wagner
2021-01-29  1:23         ` Chao Leng
2021-01-29  1:42           ` Sagi Grimberg
2021-01-29  3:07             ` Chao Leng
2021-01-29  3:30               ` Sagi Grimberg
2021-01-29  3:36                 ` Chao Leng
2021-01-29  7:06               ` Hannes Reinecke
2021-01-29  7:45                 ` Chao Leng
2021-01-29  8:33                   ` Hannes Reinecke
2021-01-29  8:46                     ` Chao Leng
2021-01-29  9:20                       ` Hannes Reinecke
2021-02-01  2:16                         ` Chao Leng
2021-02-01  7:29                           ` Hannes Reinecke
2021-02-01  8:47                             ` Chao Leng
2021-02-01  8:57                               ` Hannes Reinecke
2021-02-01  9:40                                 ` Chao Leng
2021-02-01 10:45                                   ` Hannes Reinecke
2021-02-02  1:12                                     ` Chao Leng
2021-01-28  1:36 ` Chao Leng

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=c91cb4df-6736-bc0f-9d33-ecc3e2f4f510@huawei.com \
    --to=lengchao@huawei.com \
    --cc=axboe@fb.com \
    --cc=dwagner@suse.de \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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