All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
	Chao Leng <lengchao@huawei.com>
Cc: Ming Lei <ming.lei@redhat.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 06/14] nvme: don't unquiesce the admin queue in nvme_kill_queues
Date: Wed, 2 Nov 2022 01:24:10 +0000	[thread overview]
Message-ID: <b9226179-261c-b6f3-4b3c-91d2fbe02013@nvidia.com> (raw)
In-Reply-To: <20221101150050.3510-7-hch@lst.de>

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


  reply	other threads:[~2022-11-02  1:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 15:00 per-tagset SRCU struct and quiesce v3 Christoph Hellwig
2022-11-01 15:00 ` [PATCH 01/14] block: set the disk capacity to 0 in blk_mark_disk_dead Christoph Hellwig
2022-11-02  1:18   ` Chaitanya Kulkarni
2022-11-02 14:35   ` Jens Axboe
2022-11-01 15:00 ` [PATCH 02/14] nvme-pci: refactor the tagset handling in nvme_reset_work Christoph Hellwig
2022-11-02  1:19   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 03/14] nvme: don't remove namespaces in nvme_passthru_end Christoph Hellwig
2022-11-02  1:20   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 04/14] nvme: remove the NVME_NS_DEAD check in nvme_remove_invalid_namespaces Christoph Hellwig
2022-11-02  1:21   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 05/14] nvme: remove the NVME_NS_DEAD check in nvme_validate_ns Christoph Hellwig
2022-11-02  1:21   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 06/14] nvme: don't unquiesce the admin queue in nvme_kill_queues Christoph Hellwig
2022-11-02  1:24   ` Chaitanya Kulkarni [this message]
2022-11-01 15:00 ` [PATCH 07/14] nvme: split nvme_kill_queues Christoph Hellwig
2022-11-02  1:25   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 08/14] nvme-pci: don't unquiesce the I/O queues in nvme_remove_dead_ctrl Christoph Hellwig
2022-11-02  1:26   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 09/14] nvme-apple: don't unquiesce the I/O queues in apple_nvme_reset_work Christoph Hellwig
2022-11-02  5:47   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 10/14] blk-mq: skip non-mq queues in blk_mq_quiesce_queue Christoph Hellwig
2022-11-02  5:47   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 11/14] blk-mq: move the srcu_struct used for quiescing to the tagset Christoph Hellwig
2022-11-02  5:49   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 12/14] blk-mq: pass a tagset to blk_mq_wait_quiesce_done Christoph Hellwig
2022-11-02  5:50   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 13/14] blk-mq: add tagset quiesce interface Christoph Hellwig
2022-11-02  5:51   ` Chaitanya Kulkarni
2022-11-01 15:00 ` [PATCH 14/14] nvme: use blk_mq_[un]quiesce_tagset Christoph Hellwig
2022-11-02  5:51   ` Chaitanya Kulkarni
2022-11-21 20:44   ` Shakeel Butt
2022-11-22  2:53     ` Chao Leng
2022-11-22  6:08       ` Christoph Hellwig
2022-11-22  9:44         ` Sagi Grimberg
2022-11-22 16:40         ` Shakeel Butt
2022-11-01 15:25 ` per-tagset SRCU struct and quiesce v3 Keith Busch
2022-11-02  1:21 ` Chao Leng
2022-11-02  6:49 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9226179-261c-b6f3-4b3c-91d2fbe02013@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=lengchao@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=ming.lei@redhat.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.