diff options
| author | James Smart <jsmart2021@gmail.com> | 2018-01-12 02:21:38 +0300 |
|---|---|---|
| committer | Christoph Hellwig <hch@lst.de> | 2018-01-17 19:55:02 +0300 |
| commit | 0fd997d3f77296522e836f7002e8a0636c9886aa (patch) | |
| tree | 3b7880700121db30b5f889afc75795560cb2f74f /drivers/nvme | |
| parent | d625d05ef0f0914a706d824fab85472a42be6659 (diff) | |
| download | linux-0fd997d3f77296522e836f7002e8a0636c9886aa.tar.xz | |
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')
| -rw-r--r-- | drivers/nvme/host/fc.c | 3 |
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 |