All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Keith Busch <keith.busch@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>, Keith Busch <keith.busch@intel.com>,
	Laurence Oberman <loberman@redhat.com>,
	Sagi Grimberg <sagi@grimberg.me>,
	James Smart <james.smart@broadcom.com>,
	linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
	Johannes Thumshirn <jthumshirn@suse.de>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 3/6] nvme: Move all IO out of controller reset
Date: Tue, 22 May 2018 00:04:53 +0800	[thread overview]
Message-ID: <20180521160452.GD19099@ming.t460p> (raw)
In-Reply-To: <20180521154433.GJ5528@localhost.localdomain>

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:
> > 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

WARNING: multiple messages have this Message-ID (diff)
From: ming.lei@redhat.com (Ming Lei)
Subject: [PATCH 3/6] nvme: Move all IO out of controller reset
Date: Tue, 22 May 2018 00:04:53 +0800	[thread overview]
Message-ID: <20180521160452.GD19099@ming.t460p> (raw)
In-Reply-To: <20180521154433.GJ5528@localhost.localdomain>

On Mon, May 21, 2018@09:44:33AM -0600, Keith Busch wrote:
> On Mon, May 21, 2018@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.

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

  reply	other threads:[~2018-05-21 16:04 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18 16:38 [PATCH 1/6] nvme: Sync request queues on reset Keith Busch
2018-05-18 16:38 ` Keith Busch
2018-05-18 16:38 ` [PATCH 2/6] nvme-pci: Fix queue freeze criteria " Keith Busch
2018-05-18 16:38   ` Keith Busch
2018-05-18 16:38 ` [PATCH 3/6] nvme: Move all IO out of controller reset Keith Busch
2018-05-18 16:38   ` Keith Busch
2018-05-18 23:03   ` Ming Lei
2018-05-18 23:03     ` Ming Lei
2018-05-21 14:22     ` Keith Busch
2018-05-21 14:22       ` Keith Busch
2018-05-21 14:58       ` Ming Lei
2018-05-21 14:58         ` Ming Lei
2018-05-21 15:03         ` Keith Busch
2018-05-21 15:03           ` Keith Busch
2018-05-21 15:34           ` Ming Lei
2018-05-21 15:34             ` Ming Lei
2018-05-21 15:44             ` Keith Busch
2018-05-21 15:44               ` Keith Busch
2018-05-21 16:04               ` Ming Lei [this message]
2018-05-21 16:04                 ` Ming Lei
2018-05-21 16:23                 ` Keith Busch
2018-05-21 16:23                   ` Keith Busch
2018-05-22  1:46                   ` Ming Lei
2018-05-22  1:46                     ` Ming Lei
2018-05-22 14:03                     ` Keith Busch
2018-05-22 14:03                       ` Keith Busch
2018-05-18 16:38 ` [PATCH 4/6] nvme: Allow reset from CONNECTING state Keith Busch
2018-05-18 16:38   ` Keith Busch
2018-05-18 16:38 ` [PATCH 5/6] nvme-pci: Attempt reset retry for IO failures Keith Busch
2018-05-18 16:38   ` Keith Busch
2018-05-18 16:38 ` [PATCH 6/6] nvme-pci: Rate limit the nvme timeout warnings Keith Busch
2018-05-18 16:38   ` Keith Busch
2018-05-18 22:32 ` [PATCH 1/6] nvme: Sync request queues on reset Ming Lei
2018-05-18 22:32   ` Ming Lei
2018-05-18 23:44   ` Keith Busch
2018-05-18 23:44     ` Keith Busch
2018-05-19  0:01     ` Ming Lei
2018-05-19  0:01       ` Ming Lei
2018-05-21 14:04       ` Keith Busch
2018-05-21 14:04         ` Keith Busch
2018-05-21 15:25         ` Ming Lei
2018-05-21 15:25           ` Ming Lei
2018-05-21 15:59           ` Keith Busch
2018-05-21 15:59             ` Keith Busch
2018-05-21 16:08             ` Ming Lei
2018-05-21 16:08               ` Ming Lei
2018-05-21 16:25               ` Keith Busch
2018-05-21 16:25                 ` Keith Busch
2018-05-22  1:56                 ` Ming Lei
2018-05-22  1:56                   ` 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=20180521160452.GD19099@ming.t460p \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=james.smart@broadcom.com \
    --cc=jthumshirn@suse.de \
    --cc=keith.busch@intel.com \
    --cc=keith.busch@linux.intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=loberman@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.