From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>
Cc: Stefan Roese <sr@denx.de>,
Matthew Rosato <mjrosato@linux.ibm.com>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] nvme-pci: fix hang during error recovery when the PCI device is isolated
Date: Tue, 12 Jul 2022 14:44:52 +0200 [thread overview]
Message-ID: <20220712124453.2227362-1-schnelle@linux.ibm.com> (raw)
Hi Christoph, Hi Keith,
I found a regression when recovering NVMes after a simulated PCI error on
s390, though I believe at least some POWER systems should be affected as
well. I tracked this down to commit b98235d3a471 ("nvme-pci: harden drive
presence detect in nvme_dev_disable()") which causes nvme_start_freeze() to
not be called before nvme_reset_work() does nvme_wait_freeze() thus hanging
forever. The detailed analysis is included in the commit message and not
too complex but I'm not entirely sure my proposed solution is the correct
one.
The patch I'm sending here works for me and should at least only affect
platforms using the explicit driver->err_handler->slot_reset callback. To
my understanding it seems that the nvme_dev_disable() in
nvme_error_detected() still does the necessary quiescing towards upper
layers and I assume that nvme_start_freeze() won't do anything useful if
the controller is inaccessible but I'm not an expert in this. In particular
I'm not sure it makes sense to start freezing the queues right after
a reset.
Also note I will be travelling for about 3 weeks starting July 14th and
won't have access to s390 machines or my work mail address so apologies if
I won't answer. Feel free to do your own fix. Also Matt (on CC) might be
able to test fixes for this.
Best regards,
Niklas
Niklas Schnelle (1):
nvme-pci: fix hang during error recovery when the PCI device is
isolated
drivers/nvme/host/pci.c | 1 +
1 file changed, 1 insertion(+)
--
2.34.1
next reply other threads:[~2022-07-12 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 12:44 Niklas Schnelle [this message]
2022-07-12 12:44 ` [PATCH 1/1] " Niklas Schnelle
2022-07-12 13:49 ` Hannes Reinecke
2022-07-12 14:05 ` Niklas Schnelle
2022-07-12 14:17 ` Keith Busch
2022-07-12 14:36 ` Niklas Schnelle
2022-07-18 9:30 ` Stefan Roese
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=20220712124453.2227362-1-schnelle@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mjrosato@linux.ibm.com \
--cc=sr@denx.de \
/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
all inboxes | Powered by JetHome®