[PATCH 1/3] nvme: ensure unquiesce on teardown

[PATCH 1/3] nvme: ensure unquiesce on teardown

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

The reset work is called on quiesced IO queues, so ensure these are
unquiesced after a failed reset to flush out any pending requests.

Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index b027e5e3f4acb..8eaa954aa6ed4 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2778,6 +2778,7 @@ static void nvme_reset_work(struct work_struct *work)
 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
 	nvme_dev_disable(dev, true);
 	nvme_mark_namespaces_dead(&dev->ctrl);
+	nvme_unquiesce_io_queues(&dev->ctrl);
 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DEAD);
 }
 
-- 
2.34.1

[PATCH 2/3] nvme: sync timeout work on failed reset

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

Timeouts during reset will set the controller for failure, preventing
the state change to LIVE. Ensure all timeout work is synced after the
controller disabling completes so we don't have any other tasks messing
with any namespace request_queues.

Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 8eaa954aa6ed4..bfeadecf9e15b 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2777,6 +2777,7 @@ static void nvme_reset_work(struct work_struct *work)
 		 result);
 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING);
 	nvme_dev_disable(dev, true);
+	nvme_sync_queues(&dev->ctrl);
 	nvme_mark_namespaces_dead(&dev->ctrl);
 	nvme_unquiesce_io_queues(&dev->ctrl);
 	nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DEAD);
-- 
2.34.1

[PATCH 3/3] nvme: disable controller on reset state failure

[Keith Busch]

From: Keith Busch <kbusch@kernel.org>

If the controller is not in a RESETTING state at the point of reset
work, we have to conclude the controller is being deleted. Go to the
cleanup on this condition to ensure proper pairing of request_queue
quiesce state.

Signed-off-by: Keith Busch <kbusch@kernel.org>
---
 drivers/nvme/host/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index bfeadecf9e15b..c9224d39195e5 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2690,7 +2690,8 @@ static void nvme_reset_work(struct work_struct *work)
 	if (dev->ctrl.state != NVME_CTRL_RESETTING) {
 		dev_warn(dev->ctrl.device, "ctrl state %d is not RESETTING\n",
 			 dev->ctrl.state);
-		return;
+		result = -ENODEV;
+		goto out;
 	}
 
 	/*
-- 
2.34.1

Re: [PATCH 1/3] nvme: ensure unquiesce on teardown

[Christoph Hellwig]

On Wed, Jun 28, 2023 at 07:58:12AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> The reset work is called on quiesced IO queues, so ensure these are
> unquiesced after a failed reset to flush out any pending requests.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 2/3] nvme: sync timeout work on failed reset

[Christoph Hellwig]

On Wed, Jun 28, 2023 at 07:58:13AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> Timeouts during reset will set the controller for failure, preventing
> the state change to LIVE. Ensure all timeout work is synced after the
> controller disabling completes so we don't have any other tasks messing
> with any namespace request_queues.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 3/3] nvme: disable controller on reset state failure

[Christoph Hellwig]

On Wed, Jun 28, 2023 at 07:58:14AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> If the controller is not in a RESETTING state at the point of reset
> work, we have to conclude the controller is being deleted. Go to the
> cleanup on this condition to ensure proper pairing of request_queue
> quiesce state.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>