All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Chao Leng <lengchao@huawei.com>, Christoph Hellwig <hch@lst.de>,
	linux-nvme@lists.infradead.org, Yi Zhang <yi.zhang@redhat.com>,
	Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH 2/2] nvme-pci: don't wait freeze during resetting
Date: Thu, 25 Aug 2022 22:15:08 +0800	[thread overview]
Message-ID: <YweD7HkrNeiivHZO@T590> (raw)
In-Reply-To: <Ywd8VLKPmDS7QmBu@kbusch-mbp.dhcp.thefacebook.com>

On Thu, Aug 25, 2022 at 07:42:44AM -0600, Keith Busch wrote:
> On Thu, Aug 25, 2022 at 07:34:30PM +0800, Ming Lei wrote:
> > On Thu, Aug 25, 2022 at 06:05:30PM +0800, Chao Leng wrote:
> > > 
> > > 
> > > On 2022/8/21 16:47, Ming Lei wrote:
> > > > First it isn't necessary to call nvme_wait_freeze in nvme_reset_work().
> > > > If tagset isn't allocated, there can't be any inflight IOs; otherwise
> > > > blk_mq_update_nr_hw_queues can freeze & wait queues.
> > > > 
> > > > Second, since commit bdd6316094e0 ("block: Allow unfreezing of a queue
> > > > while requests are in progress"), it is fine to unfreeze queue without
> > > > draining inflight IOs.
> > > > 
> > > > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > > > ---
> > > >   drivers/nvme/host/pci.c | 1 -
> > > >   1 file changed, 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > > > index 3a1c37f32f30..91b2903fcc24 100644
> > > > --- a/drivers/nvme/host/pci.c
> > > > +++ b/drivers/nvme/host/pci.c
> > > > @@ -2910,7 +2910,6 @@ static void nvme_reset_work(struct work_struct *work)
> > > >   		nvme_free_tagset(dev);
> > > >   	} else {
> > > >   		nvme_start_queues(&dev->ctrl);
> > > > -		nvme_wait_freeze(&dev->ctrl);
> > > It is not safe.
> > > nvme_dev_add may call blk_mq_update_nr_hw_queues, blk_mq_update_nr_hw_queues
> > > require the state is frozen.
> > 
> > blk_mq_update_nr_hw_queues() calls blk_freeze_queue() for every queue in
> > this tagset, so it needn't nvme's freeze wait.
> 
> Right, the blk-mq realloc should be fine, and it's really a very uncommon event
> that nvme needs to realloc the tag set.
> 
> I'm trying to remember why I added the wait freeze here in the first place, and
> I don't recall a good reason for it. I think I had a controller that always
> timed out IO, and the resets would just continue indefinitely. Waiting for
> freeze within a reset causes the next IO timeout to trigger a driver detach.
> That doesn't sound like a good idea, though, since it tears down the admin
> queue too.

The wait becomes not necessary since commit bdd6316094e0 ("block: Allow unfreezing
of a queue while requests are in progress").


Thanks,
Ming



  reply	other threads:[~2022-08-25 14:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-21  8:47 [PATCH 0/2] nvme: make NVMe freeze API reliably Ming Lei
2022-08-21  8:47 ` [PATCH 1/2] " Ming Lei
2022-08-24 11:15   ` Hannes Reinecke
2022-08-24 14:07     ` Keith Busch
2022-08-25 10:02   ` Chao Leng
2022-09-06  4:49     ` Christoph Hellwig
2022-09-06  8:45     ` Ming Lei
2022-09-06  9:32       ` Chao Leng
2022-09-07  0:33         ` Ming Lei
2022-09-07  1:18           ` Chao Leng
2022-09-07  2:06             ` Ming Lei
2022-09-07  5:58               ` Chao Leng
2022-08-28 14:37   ` Sagi Grimberg
2022-08-21  8:47 ` [PATCH 2/2] nvme-pci: don't wait freeze during resetting Ming Lei
2022-08-25 10:05   ` Chao Leng
2022-08-25 11:34     ` Ming Lei
2022-08-25 13:42       ` Keith Busch
2022-08-25 14:15         ` Ming Lei [this message]
2022-08-26  1:27           ` Chao Leng
2022-08-28 14:37   ` Sagi Grimberg
2022-09-06  4:49   ` Christoph Hellwig
2022-08-24 11:57 ` [PATCH 0/2] nvme: make NVMe freeze API reliably Yi Zhang
2022-09-19 14:52 ` Christoph Hellwig
2022-09-20  0:51   ` Ming Lei

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=YweD7HkrNeiivHZO@T590 \
    --to=ming.lei@redhat.com \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=lengchao@huawei.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=yi.zhang@redhat.com \
    /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.