From: ming.lei@redhat.com (Ming Lei)
Subject: [PATCH 3/6] nvme-pci: Unblock reset_work on IO failure
Date: Thu, 16 May 2019 11:13:35 +0800 [thread overview]
Message-ID: <20190516031333.GC16342@ming.t460p> (raw)
In-Reply-To: <20190515163625.21776-3-keith.busch@intel.com>
On Wed, May 15, 2019@10:36:22AM -0600, Keith Busch wrote:
> The reset_work waits in the connecting state for previously queued IO to
> complete before setting the controller to live. If these requests time
> out, we won't be able to restart the controller because the reset_work
> is already running, and any requeued IOs will block reset_work forever.
>
> When connecting, shutdown the controller to flush all entered requests
> to a failed completion if a timeout occurs, and ensure the controller
> can't transition to the live state after we've unblocked it. The driver
> will instead unbind from the controller if we can't complete IO during
> initialization.
>
> Signed-off-by: Keith Busch <keith.busch at intel.com>
> ---
> drivers/nvme/host/pci.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index c72755311ffa..8df176ffcbc1 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1257,7 +1257,6 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
> struct nvme_dev *dev = nvmeq->dev;
> struct request *abort_req;
> struct nvme_command cmd;
> - bool shutdown = false;
> u32 csts = readl(dev->bar + NVME_REG_CSTS);
>
> /* If PCI error recovery process is happening, we cannot reset or
> @@ -1294,14 +1293,14 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
> * shutdown, so we return BLK_EH_DONE.
> */
> switch (dev->ctrl.state) {
> - case NVME_CTRL_DELETING:
> - shutdown = true;
> - /* fall through */
> case NVME_CTRL_CONNECTING:
> + nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
> + /* fall through */
> + case NVME_CTRL_DELETING:
> dev_warn_ratelimited(dev->ctrl.device,
> "I/O %d QID %d timeout, disable controller\n",
> req->tag, nvmeq->qid);
> - nvme_dev_disable(dev, shutdown);
> + nvme_dev_disable(dev, true);
> nvme_req(req)->flags |= NVME_REQ_CANCELLED;
> return BLK_EH_DONE;
> case NVME_CTRL_RESETTING:
Then the controller is dead, and can't work any more together with data
loss. I guess this way is too violent from user view.
Thanks,
Ming
next prev parent reply other threads:[~2019-05-16 3:13 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-15 16:36 [PATCH 1/6] nvme-pci: Fix controller freeze wait disabling Keith Busch
2019-05-15 16:36 ` [PATCH 2/6] nvme-pci: Don't disable on timeout in reset state Keith Busch
2019-05-16 3:07 ` Ming Lei
2019-05-16 14:33 ` Keith Busch
2019-05-16 6:27 ` Christoph Hellwig
2019-05-15 16:36 ` [PATCH 3/6] nvme-pci: Unblock reset_work on IO failure Keith Busch
2019-05-16 3:13 ` Ming Lei [this message]
2019-05-16 14:14 ` Keith Busch
2019-05-17 2:31 ` Ming Lei
2019-05-16 6:28 ` Christoph Hellwig
2019-05-15 16:36 ` [PATCH 4/6] nvme-pci: Sync queues on reset Keith Busch
2019-05-16 3:34 ` Ming Lei
2019-05-16 6:29 ` Christoph Hellwig
2019-05-16 14:08 ` Keith Busch
2019-05-16 13:43 ` Minwoo Im
2019-05-15 16:36 ` [PATCH 5/6] nvme: Export get and set features Keith Busch
2019-05-16 6:26 ` Christoph Hellwig
2019-05-16 13:47 ` Minwoo Im
2019-05-15 16:36 ` [PATCHv2 6/6] nvme-pci: Use host managed power state for suspend Keith Busch
2019-05-15 19:33 ` Mario.Limonciello
2019-05-15 19:34 ` Keith Busch
2019-05-15 19:43 ` Mario.Limonciello
2019-05-16 6:25 ` Christoph Hellwig
2019-05-16 14:24 ` Keith Busch
2019-05-17 9:08 ` Christoph Hellwig
2019-05-16 9:29 ` Rafael J. Wysocki
2019-05-16 14:26 ` Keith Busch
2019-05-16 18:27 ` Kai-Heng Feng
2019-05-16 18:33 ` Mario.Limonciello
2019-05-16 19:38 ` Keith Busch
2019-05-16 20:25 ` Rafael J. Wysocki
2019-05-16 20:39 ` Keith Busch
2019-05-16 20:56 ` Rafael J. Wysocki
2019-05-17 8:39 ` Rafael J. Wysocki
2019-05-17 9:05 ` Christoph Hellwig
2019-05-17 9:17 ` Rafael J. Wysocki
2019-05-17 9:35 ` Christoph Hellwig
2019-05-17 10:34 ` Rafael J. Wysocki
2019-05-22 6:47 ` Kai Heng Feng
2019-05-22 15:52 ` Christoph Hellwig
2019-05-22 16:02 ` Keith Busch
2019-05-22 16:35 ` Mario.Limonciello
2019-05-22 16:56 ` Keith Busch
2019-05-22 23:08 ` Keith Busch
2019-05-23 15:27 ` Keith Busch
2019-05-17 9:22 ` Kai-Heng Feng
2019-05-17 9:32 ` Rafael J. Wysocki
2019-05-16 20:24 ` Rafael J. Wysocki
2019-05-16 2:43 ` [PATCH 1/6] nvme-pci: Fix controller freeze wait disabling Ming Lei
2019-05-17 18:40 ` Keith Busch
2019-05-16 6:27 ` Christoph Hellwig
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=20190516031333.GC16342@ming.t460p \
--to=ming.lei@redhat.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