From: Keith Busch <hidden> Date: 2018-05-18 16:38:18
This patch fixes races that occur with simultaneous controller
resets by synchronizing request queues prior to initializing the
controller. Withouth this, a thread may attempt disabling a controller
at the same time as we're trying to enable it.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/core.c | 21 +++++++++++++++++++--
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 1 +
3 files changed, 21 insertions(+), 2 deletions(-)
From: Keith Busch <hidden> Date: 2018-05-18 16:36:28
If the reset failed due to a non-fatal error, this patch will attempt
to reset the controller again, with a maximum of 4 attempts.
Since the failed reset case has changed purpose, this patch provides a
more appropriate name and warning message for the reset failure.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/pci.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
@@ -2307,9 +2311,23 @@ static void nvme_pci_free_ctrl(struct nvme_ctrl *ctrl)kfree(dev);}-staticvoidnvme_remove_dead_ctrl(structnvme_dev*dev,intstatus)+staticvoidnvme_reset_failure(structnvme_dev*dev,intstatus){-dev_warn(dev->ctrl.device,"Removing after probe failure status: %d\n",status);+dev->reset_failures++;+dev_warn(dev->ctrl.device,"Reset failure status: %d, failures:%d\n",+status,dev->reset_failures);++/* IO and Interrupted Call may indicate a retryable error */+switch(status){+case-EIO:+case-EINTR:+if(dev->reset_failures<MAX_RESET_FAILURES&&+!nvme_reset_ctrl(&dev->ctrl))+return;+break;+default:+break;+}nvme_get_ctrl(&dev->ctrl);nvme_dev_disable(dev,false);
@@ -2410,14 +2428,16 @@ static void nvme_reset_work(struct work_struct *work)if(!nvme_change_ctrl_state(&dev->ctrl,new_state)){dev_warn(dev->ctrl.device,"failed to mark controller state %d\n",new_state);+result=-ENODEV;gotoout;}+dev->reset_failures=0;nvme_start_ctrl(&dev->ctrl);return;out:-nvme_remove_dead_ctrl(dev,result);+nvme_reset_failure(dev,result);}staticvoidnvme_remove_dead_ctrl_work(structwork_struct*work)
From: Keith Busch <hidden> Date: 2018-05-18 16:38:19
The driver had been relying on the pci_dev to maintain the state of
the pci device to know when starting a freeze would be appropriate. The
blktests block/011 however shows us that users may alter the state of
pci_dev out from under drivers and break the criteria we had been using.
This patch uses the private nvme controller struct to track the
enabling/disabling state. Since we're relying on that now, the reset will
unconditionally disable the device on reset. This is necessary anyway
on a controller failure reset, and was already being done in the reset
during admin bring up, and is not harmful to do a second time.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/pci.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
From: Keith Busch <hidden> Date: 2018-05-18 16:38:20
IO may be retryable, so don't wait for them in the reset path. These
commands may trigger a reset if that IO expires without a completion,
placing it on the requeue list. Waiting for these would then deadlock
the reset handler.
To fix the theoretical deadlock, this patch unblocks IO submission from
the reset_work as before, but moves the waiting to the IO safe scan_work
so that the reset_work may proceed to completion. Since the unfreezing
happens in the controller LIVE state, the nvme device has to track if
the queues were frozen now to prevent incorrect freeze depths.
This patch is also renaming the function 'nvme_dev_add' to a
more appropriate name that describes what it's actually doing:
nvme_alloc_io_tags.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/core.c | 3 +++
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 46 +++++++++++++++++++++++++++++++++-------------
3 files changed, 37 insertions(+), 13 deletions(-)
@@ -2097,10 +2121,7 @@ static int nvme_dev_add(struct nvme_dev *dev)nvme_dbbuf_set(dev);}else{-blk_mq_update_nr_hw_queues(&dev->tagset,dev->online_queues-1);--/* Free previously allocated queues that are no longer usable */-nvme_free_queues(dev,dev->online_queues);+nvme_start_queues(&dev->ctrl);}return0;
@@ -2375,13 +2399,8 @@ static void nvme_reset_work(struct work_struct *work)nvme_kill_queues(&dev->ctrl);nvme_remove_namespaces(&dev->ctrl);new_state=NVME_CTRL_ADMIN_ONLY;-}else{-nvme_start_queues(&dev->ctrl);-nvme_wait_freeze(&dev->ctrl);-/* hit this only when allocate tagset fails */-if(nvme_dev_add(dev))-new_state=NVME_CTRL_ADMIN_ONLY;-nvme_unfreeze(&dev->ctrl);+}elseif(nvme_alloc_io_tags(dev)){+new_state=NVME_CTRL_ADMIN_ONLY;}/*
From: Keith Busch <hidden> Date: 2018-05-18 16:38:21
A failed connection may be retryable. This patch allows the connecting
state to initiate a reset so that it may try to connect again.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/core.c | 1 +
1 file changed, 1 insertion(+)
From: Keith Busch <hidden> Date: 2018-05-18 16:38:23
The block layer's timeout handling currently refuses to let the driver
complete commands outside the timeout callback once blk-mq decides they've
expired. If a device breaks, this could potentially create many thousands
of timed out commands. There's nothing of value to be gleaned from
observing each of those messages, so this patch adds a ratelimit on them.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, May 18, 2018 at 10:38:18AM -0600, Keith Busch wrote:
quoted hunk
This patch fixes races that occur with simultaneous controller
resets by synchronizing request queues prior to initializing the
controller. Withouth this, a thread may attempt disabling a controller
at the same time as we're trying to enable it.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/core.c | 21 +++++++++++++++++++--
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 1 +
3 files changed, 21 insertions(+), 2 deletions(-)
This way can't sync timeout reliably, since timeout events can
come from two NS at the same time, and one may be handled as
RESET_TIMER, and another one can be handled as EH_HANDLED.
Thanks,
Ming
On Fri, May 18, 2018 at 10:38:20AM -0600, Keith Busch wrote:
quoted hunk
IO may be retryable, so don't wait for them in the reset path. These
commands may trigger a reset if that IO expires without a completion,
placing it on the requeue list. Waiting for these would then deadlock
the reset handler.
To fix the theoretical deadlock, this patch unblocks IO submission from
the reset_work as before, but moves the waiting to the IO safe scan_work
so that the reset_work may proceed to completion. Since the unfreezing
happens in the controller LIVE state, the nvme device has to track if
the queues were frozen now to prevent incorrect freeze depths.
This patch is also renaming the function 'nvme_dev_add' to a
more appropriate name that describes what it's actually doing:
nvme_alloc_io_tags.
Signed-off-by: Keith Busch <redacted>
---
drivers/nvme/host/core.c | 3 +++
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 46 +++++++++++++++++++++++++++++++++-------------
3 files changed, 37 insertions(+), 13 deletions(-)
From: Keith Busch <hidden> Date: 2018-05-18 23:44:08
On Sat, May 19, 2018 at 06:32:11AM +0800, Ming Lei wrote:
This way can't sync timeout reliably, since timeout events can
come from two NS at the same time, and one may be handled as
RESET_TIMER, and another one can be handled as EH_HANDLED.
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
from the point the syncing occurs, and they don't return RESET_TIMER,
and on top of that, the reset reclaims every single IO command no matter
what namespace request_queue initiated the reset.
On Fri, May 18, 2018 at 05:44:08PM -0600, Keith Busch wrote:
On Sat, May 19, 2018 at 06:32:11AM +0800, Ming Lei wrote:
quoted
This way can't sync timeout reliably, since timeout events can
come from two NS at the same time, and one may be handled as
RESET_TIMER, and another one can be handled as EH_HANDLED.
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
When timeouts come, the global state of RESETTING may not be updated
yet, so all the timeouts may not observe the state.
Please see my previous explanation:
https://marc.info/?l=linux-block&m=152600464317808&w=2
Thanks,
Ming
From: Keith Busch <hidden> Date: 2018-05-21 14:04:13
On Sat, May 19, 2018 at 08:01:42AM +0800, Ming Lei wrote:
quoted
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
When timeouts come, the global state of RESETTING may not be updated
yet, so all the timeouts may not observe the state.
Even prior to the RESETING state, every single command, no matter
which namespace or request_queue it came on, is reclaimed by the driver.
There *should* be no requests to timeout after nvme_dev_disable is called
because the nvme driver returned control of all requests in the tagset
to blk-mq.
In any case, if blk-mq decides it won't complete those requests, we
can just swap the order in the reset_work: sync first, uncondintionally
disable. Does the following snippet look more okay?
---
From: Keith Busch <hidden> Date: 2018-05-21 15:03:31
On Mon, May 21, 2018 at 10:58:51PM +0800, Ming Lei wrote:
On Mon, May 21, 2018 at 08:22:19AM -0600, Keith Busch wrote:
quoted
On Sat, May 19, 2018 at 07:03:58AM +0800, Ming Lei wrote:
quoted
On Fri, May 18, 2018 at 10:38:20AM -0600, Keith Busch wrote:
quoted
+
+ if (unfreeze)
+ nvme_wait_freeze(&dev->ctrl);
+
timeout may comes just before&during blk_mq_update_nr_hw_queues() or
the above nvme_wait_freeze(), then both two may hang forever.
Why would it hang forever? The scan_work doesn't stop a timeout from
triggering a reset to reclaim requests necessary to complete a freeze.
nvme_dev_disable() will quiesce queues, then nvme_wait_freeze() or
blk_mq_update_nr_hw_queues() may hang forever.
nvme_dev_disable is just the first part of the timeout sequence. You
have to follow it through to the reset_work that either restarts or
kills the queues.
On Mon, May 21, 2018 at 08:04:13AM -0600, Keith Busch wrote:
On Sat, May 19, 2018 at 08:01:42AM +0800, Ming Lei wrote:
quoted
quoted
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
When timeouts come, the global state of RESETTING may not be updated
yet, so all the timeouts may not observe the state.
Even prior to the RESETING state, every single command, no matter
which namespace or request_queue it came on, is reclaimed by the driver.
There *should* be no requests to timeout after nvme_dev_disable is called
because the nvme driver returned control of all requests in the tagset
to blk-mq.
The timed-out requests won't be canceled by nvme_dev_disable().
If the timed-out requests is handled as RESET_TIMER, there may
be new timeout event triggered again.
quoted hunk
In any case, if blk-mq decides it won't complete those requests, we
can just swap the order in the reset_work: sync first, uncondintionally
disable. Does the following snippet look more okay?
---
That may not work reliably too.
For example, request A from NS_0 is timed-out and handled as RESET_TIMER,
meantime request B from NS_1 is timed-out and handled as EH_HANDLED.
When the above reset work is run for handling timeout of req B,
new timeout event on request A may come just between the above
nvme_sync_queues() and nvme_dev_disable(), then nvme_dev_disable()
can't cover request A, and finally the timed-out event for req A
will nvme_dev_disable() when the current reset is just in-progress,
then this reset can't move on, and IO hang is caused.
Thanks,
Ming
On Mon, May 21, 2018 at 09:03:31AM -0600, Keith Busch wrote:
On Mon, May 21, 2018 at 10:58:51PM +0800, Ming Lei wrote:
quoted
On Mon, May 21, 2018 at 08:22:19AM -0600, Keith Busch wrote:
quoted
On Sat, May 19, 2018 at 07:03:58AM +0800, Ming Lei wrote:
quoted
On Fri, May 18, 2018 at 10:38:20AM -0600, Keith Busch wrote:
quoted
+
+ if (unfreeze)
+ nvme_wait_freeze(&dev->ctrl);
+
timeout may comes just before&during blk_mq_update_nr_hw_queues() or
the above nvme_wait_freeze(), then both two may hang forever.
Why would it hang forever? The scan_work doesn't stop a timeout from
triggering a reset to reclaim requests necessary to complete a freeze.
nvme_dev_disable() will quiesce queues, then nvme_wait_freeze() or
blk_mq_update_nr_hw_queues() may hang forever.
nvme_dev_disable is just the first part of the timeout sequence. You
have to follow it through to the reset_work that either restarts or
kills the queues.
nvme_dev_disable() quiesces queues first before killing queues.
If queues are quiesced during or before nvme_wait_freeze() is run
from the 2nd part of reset, the 2nd part can't move on, and IO hang
is caused. Finally no reset can be scheduled at all.
Thanks,
Ming
From: Keith Busch <hidden> Date: 2018-05-21 15:44:33
On Mon, May 21, 2018 at 11:34:27PM +0800, Ming Lei wrote:
nvme_dev_disable() quiesces queues first before killing queues.
If queues are quiesced during or before nvme_wait_freeze() is run
from the 2nd part of reset, the 2nd part can't move on, and IO hang
is caused. Finally no reset can be scheduled at all.
But this patch moves nvme_wait_freeze outside the reset path, so I'm
afraid I'm unable to follow how you've concluded the wait freeze is
somehow part of the reset.
From: Keith Busch <hidden> Date: 2018-05-21 15:59:09
On Mon, May 21, 2018 at 11:25:43PM +0800, Ming Lei wrote:
On Mon, May 21, 2018 at 08:04:13AM -0600, Keith Busch wrote:
quoted
On Sat, May 19, 2018 at 08:01:42AM +0800, Ming Lei wrote:
quoted
quoted
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
When timeouts come, the global state of RESETTING may not be updated
yet, so all the timeouts may not observe the state.
Even prior to the RESETING state, every single command, no matter
which namespace or request_queue it came on, is reclaimed by the driver.
There *should* be no requests to timeout after nvme_dev_disable is called
because the nvme driver returned control of all requests in the tagset
to blk-mq.
The timed-out requests won't be canceled by nvme_dev_disable().
??? nvme_dev_disable cancels all started requests. There are no exceptions.
If the timed-out requests is handled as RESET_TIMER, there may
be new timeout event triggered again.
quoted
In any case, if blk-mq decides it won't complete those requests, we
can just swap the order in the reset_work: sync first, uncondintionally
disable. Does the following snippet look more okay?
---
That may not work reliably too.
For example, request A from NS_0 is timed-out and handled as RESET_TIMER,
meantime request B from NS_1 is timed-out and handled as EH_HANDLED.
Meanwhile, request B's nvme_dev_disable prior to returning EH_HANDLED
cancels all requests, which includes request A.
When the above reset work is run for handling timeout of req B,
new timeout event on request A may come just between the above
nvme_sync_queues() and nvme_dev_disable()
The sync queues either stops the timer from running, or waits for it to
complete. We are in the RESETTING state: if request A's timeout happens
to be running, we're not restarting the timer; we're returning EH_HANDLED.
then nvme_dev_disable()
can't cover request A, and finally the timed-out event for req A
will nvme_dev_disable() when the current reset is just in-progress,
then this reset can't move on, and IO hang is caused.
At no point in the nvme_reset are we waiting for any IO to complete.
Reset continues to make forward progress.
On Mon, May 21, 2018 at 09:44:33AM -0600, Keith Busch wrote:
On Mon, May 21, 2018 at 11:34:27PM +0800, Ming Lei wrote:
quoted
nvme_dev_disable() quiesces queues first before killing queues.
If queues are quiesced during or before nvme_wait_freeze() is run
from the 2nd part of reset, the 2nd part can't move on, and IO hang
is caused. Finally no reset can be scheduled at all.
But this patch moves nvme_wait_freeze outside the reset path, so I'm
afraid I'm unable to follow how you've concluded the wait freeze is
somehow part of the reset.
For example:
1) the 1st timeout event:
- nvme_dev_disable()
- reset
- scan_work
2) the 2nd timeout event:
nvme_dev_disable() may come just after nvme_start_queues() in
the above reset of the 1st timeout. And nvme_timeout() won't
schedule a new reset since the controller state is NVME_CTRL_CONNECTING.
Then scan_work in 1st timeout still may hang for ever.
Thanks,
Ming
On Mon, May 21, 2018 at 09:59:09AM -0600, Keith Busch wrote:
On Mon, May 21, 2018 at 11:25:43PM +0800, Ming Lei wrote:
quoted
On Mon, May 21, 2018 at 08:04:13AM -0600, Keith Busch wrote:
quoted
On Sat, May 19, 2018 at 08:01:42AM +0800, Ming Lei wrote:
quoted
quoted
You keep saying that, but the controller state is global to the
controller. It doesn't matter which namespace request_queue started the
reset: every namespaces request queue sees the RESETTING controller state
When timeouts come, the global state of RESETTING may not be updated
yet, so all the timeouts may not observe the state.
Even prior to the RESETING state, every single command, no matter
which namespace or request_queue it came on, is reclaimed by the driver.
There *should* be no requests to timeout after nvme_dev_disable is called
because the nvme driver returned control of all requests in the tagset
to blk-mq.
The timed-out requests won't be canceled by nvme_dev_disable().
??? nvme_dev_disable cancels all started requests. There are no exceptions.
Please take a look at blk_mq_complete_request(). Even with Bart's
change, the request still won't be completed by driver. The request can
only be completed by either driver or blk-mq, not both.
quoted
If the timed-out requests is handled as RESET_TIMER, there may
be new timeout event triggered again.
quoted
In any case, if blk-mq decides it won't complete those requests, we
can just swap the order in the reset_work: sync first, uncondintionally
disable. Does the following snippet look more okay?
---
That may not work reliably too.
For example, request A from NS_0 is timed-out and handled as RESET_TIMER,
meantime request B from NS_1 is timed-out and handled as EH_HANDLED.
Meanwhile, request B's nvme_dev_disable prior to returning EH_HANDLED
cancels all requests, which includes request A.
From: Keith Busch <hidden> Date: 2018-05-21 16:23:55
On Tue, May 22, 2018 at 12:04:53AM +0800, Ming Lei wrote:
On Mon, May 21, 2018 at 09:44:33AM -0600, Keith Busch wrote:
quoted
On Mon, May 21, 2018 at 11:34:27PM +0800, Ming Lei wrote:
quoted
nvme_dev_disable() quiesces queues first before killing queues.
If queues are quiesced during or before nvme_wait_freeze() is run
from the 2nd part of reset, the 2nd part can't move on, and IO hang
is caused. Finally no reset can be scheduled at all.
But this patch moves nvme_wait_freeze outside the reset path, so I'm
afraid I'm unable to follow how you've concluded the wait freeze is
somehow part of the reset.
For example:
1) the 1st timeout event:
- nvme_dev_disable()
- reset
- scan_work
2) the 2nd timeout event:
nvme_dev_disable() may come just after nvme_start_queues() in
the above reset of the 1st timeout. And nvme_timeout() won't
schedule a new reset since the controller state is NVME_CTRL_CONNECTING.
Let me get this straight -- you're saying nvme_start_queues is going
to somehow immediately trigger timeout work? I can't see how that could
possibly happen in real life, but we can just remove it and use the existing
nvme_start_ctrl to handle that in the LIVE state.
From: Keith Busch <hidden> Date: 2018-05-21 16:25:17
On Tue, May 22, 2018 at 12:08:37AM +0800, Ming Lei wrote:
Please take a look at blk_mq_complete_request(). Even with Bart's
change, the request still won't be completed by driver. The request can
only be completed by either driver or blk-mq, not both.
So you're saying blk-mq can't complete a request the driver returned to
blk-mq to complete. And that's the nvme driver's problem to fix?
On Mon, May 21, 2018 at 10:23:55AM -0600, Keith Busch wrote:
On Tue, May 22, 2018 at 12:04:53AM +0800, Ming Lei wrote:
quoted
On Mon, May 21, 2018 at 09:44:33AM -0600, Keith Busch wrote:
quoted
On Mon, May 21, 2018 at 11:34:27PM +0800, Ming Lei wrote:
quoted
nvme_dev_disable() quiesces queues first before killing queues.
If queues are quiesced during or before nvme_wait_freeze() is run
from the 2nd part of reset, the 2nd part can't move on, and IO hang
is caused. Finally no reset can be scheduled at all.
But this patch moves nvme_wait_freeze outside the reset path, so I'm
afraid I'm unable to follow how you've concluded the wait freeze is
somehow part of the reset.
For example:
1) the 1st timeout event:
- nvme_dev_disable()
- reset
- scan_work
2) the 2nd timeout event:
nvme_dev_disable() may come just after nvme_start_queues() in
the above reset of the 1st timeout. And nvme_timeout() won't
schedule a new reset since the controller state is NVME_CTRL_CONNECTING.
Let me get this straight -- you're saying nvme_start_queues is going
to somehow immediately trigger timeout work? I can't see how that could
It may be difficult to trigger in reality, but won't be impossible
since the timeout value can be adjusted via module parameter, and any
schedule delay can be introduced in one busy system.
It isn't a good practice to rely on timing for avoiding race, IMO.
possibly happen in real life, but we can just remove it and use the existing
nvme_start_ctrl to handle that in the LIVE state.
On Mon, May 21, 2018 at 10:25:17AM -0600, Keith Busch wrote:
On Tue, May 22, 2018 at 12:08:37AM +0800, Ming Lei wrote:
quoted
Please take a look at blk_mq_complete_request(). Even with Bart's
change, the request still won't be completed by driver. The request can
only be completed by either driver or blk-mq, not both.
So you're saying blk-mq can't complete a request the driver returned to
blk-mq to complete. And that's the nvme driver's problem to fix?
For avoiding use-after-free, one request can only be completed by
one path, either by timeout path or normal completion(irq or cancel)
from driver.
So before handling this req's timeout, this request has to be
marked as completed by blk-mq timeout code already, then nvme_cancel_request()
can't cover this timed-out request.
Thanks,
Ming