From: ming.lei@redhat.com (Ming Lei)
Subject: PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable
Date: Wed, 18 Apr 2018 23:40:39 +0800 [thread overview]
Message-ID: <20180418154032.GA22533@ming.t460p> (raw)
In-Reply-To: <a6e1de6d-6086-d467-d9ce-641bcd07b983@oracle.com>
On Wed, Apr 18, 2018@10:24:28PM +0800, jianchao.wang wrote:
> Hi Ming
>
> On 04/17/2018 11:17 PM, Ming Lei wrote:
> > Looks blktest(block/011) can trigger IO hang easily on NVMe PCI device,
> > and all are related with nvme_dev_disable():
> >
> > 1) admin queue may be disabled by nvme_dev_disable() from timeout path
> > during resetting, then reset can't move on
> >
> > 2) the nvme_dev_disable() called from nvme_reset_work() may cause double
> > completion on timed-out request
> >
> > So could you share us what your plan is about this patchset?
>
> Regarding to this patchset, it is mainly to fix the dependency between
> nvme_timeout and nvme_dev_disable, as your can see:
> nvme_timeout will invoke nvme_dev_disable, and nvme_dev_disable have to
> depend on nvme_timeout when controller no response.
Do you mean nvme_disable_io_queues()? If yes, this one has been handled
by wait_for_completion_io_timeout() already, and looks the block timeout
can be disabled simply. Or are there others?
> Till now, some parts
> of the patchset looks bad and seem to have a lot of work need to be done.
> :)
Yeah, this part is much more complicated than I thought.
I think it is a good topic to discuss in the coming LSF/MM, and the NVMe
timeout(EH) may need to be refactored/cleaned up, and current issues
should be addressed in clean way.
Guys, are there other issues wrt. NVMe timeout & reset except for the
above?
Thanks,
Ming
next prev parent reply other threads:[~2018-04-18 15:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 6:19 PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Jianchao Wang
2018-03-08 6:19 ` [PATCH V4 1/5] nvme: do atomically bit operations on nvme_request.flags Jianchao Wang
2018-03-08 7:57 ` Christoph Hellwig
2018-03-08 14:32 ` jianchao.wang
2018-03-08 6:19 ` [PATCH V4 2/5] nvme: add helper interface to flush in-flight requests Jianchao Wang
2018-03-08 13:11 ` Ming Lei
2018-03-08 14:44 ` jianchao.wang
2018-03-08 18:21 ` Sagi Grimberg
2018-03-09 1:59 ` jianchao.wang
2018-03-08 6:19 ` [PATCH V4 3/5] nvme-pci: avoid nvme_dev_disable to be invoked in nvme_timeout Jianchao Wang
2018-03-09 2:01 ` jianchao.wang
2018-03-13 13:29 ` jianchao.wang
2018-03-08 6:19 ` [PATCH V4 4/5] nvme-pci: discard wait timeout when delete cq/sq Jianchao Wang
2018-03-08 6:19 ` [PATCH V4 5/5] nvme-pci: add the timeout case for DELETEING state Jianchao Wang
2018-04-17 15:17 ` PATCH V4 0/5 nvme-pci: fixes on nvme_timeout and nvme_dev_disable Ming Lei
2018-04-18 14:24 ` jianchao.wang
2018-04-18 15:40 ` Ming Lei [this message]
2018-04-19 1:51 ` jianchao.wang
2018-04-19 2:27 ` 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=20180418154032.GA22533@ming.t460p \
--to=ming.lei@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.