| Message ID | 20221101150050.3510-7-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/14] block: set the disk capacity to 0 in blk_mark_disk_dead | expand |
On 11/1/22 08:00, Christoph Hellwig wrote: > None of the callers of nvme_kill_queues needs it to unquiesce the > admin queues, as all of them already do it themselves: > > 1) nvme_reset_work explicit call nvme_start_admin_queue toward the > beginning of the function. The extra call to nvme_start_admin_queue > in nvme_reset_work this won't do anything as > NVME_CTRL_ADMIN_Q_STOPPED will already be cleared. > 2) nvme_remove calls nvme_dev_disable with shutdown flag set to true at > the very beginning of the function if the PCIe device was not present, > which is the precondition for the call to nvme_kill_queues. > nvme_dev_disable already calls nvme_start_admin_queue toward the > end of the function when the shutdown flag is set to true, so the > admin queue is already enabled at this point. > 3) nvme_remove_dead_ctrl schedules a workqueue to unbind the driver, > which will end up in nvme_remove, which calls nvme_dev_disable with > the shutdown flag. This case will call nvme_start_admin_queue a bit > later than before. > 4) apple_nvme_remove uses the same sequence as nvme_remove_dead_ctrl > above. > 5) nvme_remove_namespaces only calls nvme_kill_queues when the > controller is in the DEAD state. That can only happen in the PCIe > driver, and only from nvme_remove. See item 2) above for the > conditions there. > > So it is safe to just remove the call to nvme_start_admin_queue in > nvme_kill_queues without replacement. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > Reviewed-by: Sagi Grimberg <sagi@grimberg.me> > --- > drivers/nvme/host/core.c | 4 ---- Thanks a lot for detailed explanation.. Looks good. Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> -ck
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 871a8ab7ec199..bb62803de5b21 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -5135,10 +5135,6 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl) down_read(&ctrl->namespaces_rwsem); - /* Forcibly unquiesce queues to avoid blocking dispatch */ - if (ctrl->admin_q && !blk_queue_dying(ctrl->admin_q)) - nvme_start_admin_queue(ctrl); - list_for_each_entry(ns, &ctrl->namespaces, list) nvme_set_queue_dying(ns);
None of the callers of nvme_kill_queues needs it to unquiesce the admin queues, as all of them already do it themselves: 1) nvme_reset_work explicit call nvme_start_admin_queue toward the beginning of the function. The extra call to nvme_start_admin_queue in nvme_reset_work this won't do anything as NVME_CTRL_ADMIN_Q_STOPPED will already be cleared. 2) nvme_remove calls nvme_dev_disable with shutdown flag set to true at the very beginning of the function if the PCIe device was not present, which is the precondition for the call to nvme_kill_queues. nvme_dev_disable already calls nvme_start_admin_queue toward the end of the function when the shutdown flag is set to true, so the admin queue is already enabled at this point. 3) nvme_remove_dead_ctrl schedules a workqueue to unbind the driver, which will end up in nvme_remove, which calls nvme_dev_disable with the shutdown flag. This case will call nvme_start_admin_queue a bit later than before. 4) apple_nvme_remove uses the same sequence as nvme_remove_dead_ctrl above. 5) nvme_remove_namespaces only calls nvme_kill_queues when the controller is in the DEAD state. That can only happen in the PCIe driver, and only from nvme_remove. See item 2) above for the conditions there. So it is safe to just remove the call to nvme_start_admin_queue in nvme_kill_queues without replacement. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> --- drivers/nvme/host/core.c | 4 ---- 1 file changed, 4 deletions(-)