summaryrefslogtreecommitdiff
path: root/net/tipc
diff options
context:
space:
mode:
authorSagi Grimberg <sagi@grimberg.me>2020-09-08 22:56:08 +0300
committerChristoph Hellwig <hch@lst.de>2020-09-09 09:00:50 +0300
commit73a5379937ec89b91e907bb315e2434ee9696a2c (patch)
treeace0e6cfdb2d6217b459b1762c4cb8900547cd79 /net/tipc
parentceb1e0874dba5cbfc4e0b4145796a4bfb3716e6a (diff)
downloadlinux-73a5379937ec89b91e907bb315e2434ee9696a2c.tar.xz
nvme-fabrics: allow to queue requests for live queues
Right now we are failing requests based on the controller state (which is checked inline in nvmf_check_ready) however we should definitely accept requests if the queue is live. When entering controller reset, we transition the controller into NVME_CTRL_RESETTING, and then return BLK_STS_RESOURCE for non-mpath requests (have blk_noretry_request set). This is also the case for NVME_REQ_USER for the wrong reason. There shouldn't be any reason for us to reject this I/O in a controller reset. We do want to prevent passthru commands on the admin queue because we need the controller to fully initialize first before we let user passthru admin commands to be issued. In a non-mpath setup, this means that the requests will simply be requeued over and over forever not allowing the q_usage_counter to drop its final reference, causing controller reset to hang if running concurrently with heavy I/O. Fixes: 35897b920c8a ("nvme-fabrics: fix and refine state checks in __nvmf_check_ready") Reviewed-by: James Smart <james.smart@broadcom.com> Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'net/tipc')
0 files changed, 0 insertions, 0 deletions