From: Keith Busch <kbusch@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 1/2] blk-mq: introduce blk_mq_complete_request_sync()
Date: Mon, 18 Mar 2019 08:40:42 -0600 [thread overview]
Message-ID: <20190318144042.GA23473@localhost.localdomain> (raw)
In-Reply-To: <f708ee0c-dfa4-0bca-f996-8d834471f1fd@acm.org>
On Sun, Mar 17, 2019 at 09:09:09PM -0700, Bart Van Assche wrote:
> On 3/17/19 8:29 PM, Ming Lei wrote:
> > In NVMe's error handler, follows the typical steps for tearing down
> > hardware:
> >
> > 1) stop blk_mq hw queues
> > 2) stop the real hw queues
> > 3) cancel in-flight requests via
> > blk_mq_tagset_busy_iter(tags, cancel_request, ...)
> > cancel_request():
> > mark the request as abort
> > blk_mq_complete_request(req);
> > 4) destroy real hw queues
> >
> > However, there may be race between #3 and #4, because blk_mq_complete_request()
> > actually completes the request asynchronously.
> >
> > This patch introduces blk_mq_complete_request_sync() for fixing the
> > above race.
>
> Other block drivers wait until outstanding requests have completed by
> calling blk_cleanup_queue() before hardware queues are destroyed. Why can't
> the NVMe driver follow that approach?
You can't just wait for an outstanding request indefinitely. We have to
safely make forward progress when we've determined it's not going to be
completed.
WARNING: multiple messages have this Message-ID (diff)
From: kbusch@kernel.org (Keith Busch)
Subject: [PATCH 1/2] blk-mq: introduce blk_mq_complete_request_sync()
Date: Mon, 18 Mar 2019 08:40:42 -0600 [thread overview]
Message-ID: <20190318144042.GA23473@localhost.localdomain> (raw)
In-Reply-To: <f708ee0c-dfa4-0bca-f996-8d834471f1fd@acm.org>
On Sun, Mar 17, 2019@09:09:09PM -0700, Bart Van Assche wrote:
> On 3/17/19 8:29 PM, Ming Lei wrote:
> > In NVMe's error handler, follows the typical steps for tearing down
> > hardware:
> >
> > 1) stop blk_mq hw queues
> > 2) stop the real hw queues
> > 3) cancel in-flight requests via
> > blk_mq_tagset_busy_iter(tags, cancel_request, ...)
> > cancel_request():
> > mark the request as abort
> > blk_mq_complete_request(req);
> > 4) destroy real hw queues
> >
> > However, there may be race between #3 and #4, because blk_mq_complete_request()
> > actually completes the request asynchronously.
> >
> > This patch introduces blk_mq_complete_request_sync() for fixing the
> > above race.
>
> Other block drivers wait until outstanding requests have completed by
> calling blk_cleanup_queue() before hardware queues are destroyed. Why can't
> the NVMe driver follow that approach?
You can't just wait for an outstanding request indefinitely. We have to
safely make forward progress when we've determined it's not going to be
completed.
next prev parent reply other threads:[~2019-03-18 14:39 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-18 3:29 [PATCH 0/2] blk-mq/nvme: cancel request synchronously Ming Lei
2019-03-18 3:29 ` Ming Lei
2019-03-18 3:29 ` [PATCH 1/2] blk-mq: introduce blk_mq_complete_request_sync() Ming Lei
2019-03-18 3:29 ` Ming Lei
2019-03-18 4:09 ` Bart Van Assche
2019-03-18 4:09 ` Bart Van Assche
2019-03-18 7:38 ` Ming Lei
2019-03-18 7:38 ` Ming Lei
2019-03-18 15:04 ` Bart Van Assche
2019-03-18 15:04 ` Bart Van Assche
2019-03-18 15:16 ` Ming Lei
2019-03-18 15:16 ` Ming Lei
2019-03-18 15:49 ` Bart Van Assche
2019-03-18 15:49 ` Bart Van Assche
2019-03-18 16:06 ` Ming Lei
2019-03-18 16:06 ` Ming Lei
2019-03-21 0:47 ` Sagi Grimberg
2019-03-21 0:47 ` Sagi Grimberg
2019-03-21 1:39 ` Ming Lei
2019-03-21 1:39 ` Ming Lei
2019-03-21 2:04 ` Sagi Grimberg
2019-03-21 2:04 ` Sagi Grimberg
2019-03-21 2:32 ` Ming Lei
2019-03-21 2:32 ` Ming Lei
2019-03-21 21:40 ` Sagi Grimberg
2019-03-21 21:40 ` Sagi Grimberg
2019-03-27 8:27 ` Christoph Hellwig
2019-03-27 8:27 ` Christoph Hellwig
2019-03-21 2:15 ` Bart Van Assche
2019-03-21 2:15 ` Bart Van Assche
2019-03-21 2:13 ` Sagi Grimberg
2019-03-21 2:13 ` Sagi Grimberg
2019-03-18 14:40 ` Keith Busch [this message]
2019-03-18 14:40 ` Keith Busch
2019-03-18 17:30 ` James Smart
2019-03-18 17:30 ` James Smart
2019-03-18 17:37 ` James Smart
2019-03-18 17:37 ` James Smart
2019-03-19 1:06 ` Ming Lei
2019-03-19 1:06 ` Ming Lei
2019-03-19 3:37 ` James Smart
2019-03-19 3:37 ` James Smart
2019-03-19 3:50 ` Ming Lei
2019-03-19 3:50 ` Ming Lei
2019-03-19 1:31 ` Ming Lei
2019-03-19 1:31 ` Ming Lei
2019-03-19 4:04 ` James Smart
2019-03-19 4:04 ` James Smart
2019-03-19 4:28 ` Ming Lei
2019-03-19 4:28 ` Ming Lei
2019-03-27 8:30 ` Christoph Hellwig
2019-03-27 8:30 ` Christoph Hellwig
2019-03-18 3:29 ` [PATCH 2/2] nvme: cancel request synchronously Ming Lei
2019-03-18 3:29 ` Ming Lei
2019-03-27 8:30 ` Christoph Hellwig
2019-03-27 8:30 ` Christoph Hellwig
2019-03-27 2:06 ` [PATCH 0/2] blk-mq/nvme: " Ming Lei
2019-03-27 2:06 ` 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=20190318144042.GA23473@localhost.localdomain \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=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.