summaryrefslogtreecommitdiffstats
path: root/drivers/nvme/host/fc.c
diff options
context:
space:
mode:
authorJames Smart <jsmart2021@gmail.com>2018-01-12 00:21:38 +0100
committerChristoph Hellwig <hch@lst.de>2018-01-17 17:55:02 +0100
commit0fd997d3f77296522e836f7002e8a0636c9886aa (patch)
tree3b7880700121db30b5f889afc75795560cb2f74f /drivers/nvme/host/fc.c
parentnvme-fc: fix rogue admin cmds stalling teardown (diff)
downloadlinux-0fd997d3f77296522e836f7002e8a0636c9886aa.tar.xz
linux-0fd997d3f77296522e836f7002e8a0636c9886aa.zip
nvme-fc: correct hang in nvme_ns_remove()
When connectivity is lost to a device, the association is terminated and the blk-mq queues are quiesced/stopped. When connectivity is re-established, they are resumed. If connectivity is lost for a sufficient amount of time that the controller is then deleted, the delete path starts tearing down queues, and eventually calling nvme_ns_remove(). It appears that pending commands may cause blk_cleanup_queue() to never complete and the teardown stalls. Correct by starting the ns queues after transitioning to a DELETING state, allowing pending commands to be flushed with io failures. Thus the delete path is clear when reached. Signed-off-by: James Smart <james.smart@broadcom.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'drivers/nvme/host/fc.c')
-rw-r--r--drivers/nvme/host/fc.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index a10c77139f76..b76ba4629e02 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -2938,6 +2938,9 @@ nvme_fc_delete_ctrl(struct nvme_ctrl *nctrl)
* waiting for io to terminate
*/
nvme_fc_delete_association(ctrl);
+
+ /* resume the io queues so that things will fast fail */
+ nvme_start_queues(nctrl);
}
static void