]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
nvme-pci: fix stuck reset on concurrent DPC and HP
authorKeith Busch <kbusch@kernel.org>
Thu, 6 Mar 2025 22:25:57 +0000 (14:25 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Apr 2025 12:39:31 +0000 (14:39 +0200)
commit3e6ce0d9ec796860af31fcd77fe4120dd3c73d56
treef0c60b94dbc18b9c8f09fbe9171bc39f45fdc9e4
parent5e194e0f77ee5c5c1e9ab2b6114fbfdd1bbce519
nvme-pci: fix stuck reset on concurrent DPC and HP

[ Upstream commit 3f674e7b670b7b7d9261935820e4eba3c059f835 ]

The PCIe error handling has the nvme driver quiesce the device, attempt
to restart it, then wait for that restart to complete.

A PCIe DPC event also toggles the PCIe link. If the slot doesn't have
out-of-band presence detection, this will trigger a pciehp
re-enumeration.

The error handling that calls nvme_error_resume is holding the device
lock while this happens. This lock blocks pciehp's request to disconnect
the driver from proceeding.

Meanwhile the nvme's reset can't make forward progress because its
device isn't there anymore with outstanding IO, and the timeout handler
won't do anything to fix it because the device is undergoing error
handling.

End result: deadlocked.

Fix this by having the timeout handler short cut the disabling for a
disconnected PCIe device. The downside is that we're relying on an IO
timeout to clean up this mess, which could be a minute by default.

Tested-by: Nilay Shroff <nilay@linux.ibm.com>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/nvme/host/pci.c