summaryrefslogtreecommitdiffstats
path: root/drivers/bus
diff options
context:
space:
mode:
authorRuozhu Li <liruozhu@huawei.com>2021-11-04 15:13:32 +0800
committerChristoph Hellwig <hch@lst.de>2021-12-07 18:21:16 +0100
commit8b77fa6fdce0fc7147bab91b1011048758290ca4 (patch)
tree3fdbaf4e2f876d1a0856e016231844a8e025f1c7 /drivers/bus
parentc7c15ae3dc50c0ab46c5cbbf8d2f3d3307e51f37 (diff)
downloadlinux-stable-8b77fa6fdce0fc7147bab91b1011048758290ca4.tar.gz
linux-stable-8b77fa6fdce0fc7147bab91b1011048758290ca4.tar.bz2
linux-stable-8b77fa6fdce0fc7147bab91b1011048758290ca4.zip
nvme: fix use after free when disconnecting a reconnecting ctrl
A crash happens when trying to disconnect a reconnecting ctrl: 1) The network was cut off when the connection was just established, scan work hang there waiting for some IOs complete. Those I/Os were retried because we return BLK_STS_RESOURCE to blk in reconnecting. 2) After a while, I tried to disconnect this connection. This procedure also hangs because it tried to obtain ctrl->scan_lock. It should be noted that now we have switched the controller state to NVME_CTRL_DELETING. 3) In nvme_check_ready(), we always return true when ctrl->state is NVME_CTRL_DELETING, so those retrying I/Os were issued to the bottom device which was already freed. To fix this, when ctrl->state is NVME_CTRL_DELETING, issue cmd to bottom device only when queue state is live. If not, return host path error to the block layer Signed-off-by: Ruozhu Li <liruozhu@huawei.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'drivers/bus')
0 files changed, 0 insertions, 0 deletions