From: Greg KH <gregkh@linuxfoundation.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: stable@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH stable 5.4+] nvme: fix possible hang when ns scanning fails during error recovery
Date: Thu, 7 May 2020 09:03:17 +0200 [thread overview]
Message-ID: <20200507070317.GB841650@kroah.com> (raw)
In-Reply-To: <20200506231451.23145-1-sagi@grimberg.me>
On Wed, May 06, 2020 at 04:14:51PM -0700, Sagi Grimberg wrote:
> When the controller is reconnecting, the host fails I/O and admin
> commands as the host cannot reach the controller. ns scanning may
> revalidate namespaces during that period and it is wrong to remove
> namespaces due to these failures as we may hang (see 205da2434301).
>
> One command that may fail is nvme_identify_ns_descs. Since we return
> success due to having ns descriptor list optional, we continue to
> validate ns identifiers in nvme_revalidate_disk, obviously fail and
> return -ENODEV to nvme_validate_ns, which will remove the namespace.
>
> Exactly what we don't want to happen.
>
> Fixes: 22802bf742c2 ("nvme: Namepace identification descriptor list is optional")
> Tested-by: Anton Eidelman <anton@lightbitslabs.com>
> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
>
> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
> ---
> drivers/nvme/host/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
What is the git commit id of this patch in Linus's tree?
And why sign-off on a patch twice with a blank line?
thanks,
greg k-h
next prev parent reply other threads:[~2020-05-07 7:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 23:14 [PATCH stable 5.4+] nvme: fix possible hang when ns scanning fails during error recovery Sagi Grimberg
2020-05-07 7:03 ` Greg KH [this message]
2020-05-08 0:45 ` Sagi Grimberg
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=20200507070317.GB841650@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=sagi@grimberg.me \
--cc=stable@vger.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.