[PATCH v3 1/1] nvme-pci : Fix EEH failure on ppc after subsystem reset
Maurizio Lombardi
mlombard at redhat.com
Mon Jun 10 05:32:42 PDT 2024
út 4. 6. 2024 v 11:16 odesílatel Nilay Shroff <nilay at linux.ibm.com> napsal:
>
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index f5d150c62955..afb8419566a9 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -562,6 +562,7 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
> switch (old_state) {
> case NVME_CTRL_NEW:
> case NVME_CTRL_LIVE:
> + case NVME_CTRL_CONNECTING:
> changed = true;
> fallthrough;
> default:
Side note:
I believe this could fix a race condition in the nvme-tcp driver.
Some time ago we received a kernel dump where the controller was
flagged as NVME_CTRL_LIVE but the sockets were marked as TCP_CLOSED,
the kernel was hanging into io_work.
It might be possible that the socket's nvme_tcp_error_recovery
callback was executed while the ctrl was still marked as
NVME_CTRL_CONNECTING, nvme_change_ctrl_state() doesn't allow a
reconnecting controller to switch to the resetting state and therefore
nvme_tcp_error_recovery() simply returns without triggering an error
recovery.
nvme_tcp_setup_ctrl() then moves the ctrl to the LIVE state, but with
closed tcp sockets.
I guess that this change would fix the possible race condition, even
if I am not completely sure what could happen in case of a race
between nvme_tcp_setup_ctrl() and the error recovery code.
Maurizio
More information about the Linux-nvme
mailing list