From: Mike Snitzer <snitzer@redhat.com>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: axboe@kernel.dk, device-mapper development <dm-devel@redhat.com>,
hch@lst.de
Subject: Re: [PATCH 8/9] dm: Fix two race conditions related to stopping and starting queues
Date: Wed, 31 Aug 2016 23:13:55 -0400 [thread overview]
Message-ID: <20160901031355.GB4741@redhat.com> (raw)
In-Reply-To: <82ff8574-8b73-8ba3-9098-741060f38fca@sandisk.com>
On Wed, Aug 31 2016 at 6:18pm -0400,
Bart Van Assche <bart.vanassche@sandisk.com> wrote:
> Ensure that all ongoing dm_mq_queue_rq() and dm_mq_requeue_request()
> calls have stopped before setting the "queue stopped" flag. This
> allows to remove the "queue stopped" test from dm_mq_queue_rq() and
> dm_mq_requeue_request(). Use BLK_MQ_S_STOPPED instead of
> QUEUE_FLAG_STOPPED.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
At first glance, at a minimum this patch needs a better header. It
seems you're doing 2 things:
1) using blk_mq_{freeze,unfreeze}_queue() actually makes dm_stop_queue()
work for blk-mq? Whereby fixing blk-mq race(s)?
2) switching away from QUEUE_FLAG_STOPPED to BLK_MQ_S_STOPPED (via
blk_mq_queue_stopped)
- not clear to me that dm-mq's use of QUEUE_FLAG_STOPPED wasn't fine;
NVMe also uses it for blk-mq
> ---
> drivers/md/dm-rq.c | 29 +++++++----------------------
> 1 file changed, 7 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index 8dc8cfb..b5db523 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -78,7 +78,6 @@ void dm_start_queue(struct request_queue *q)
> if (!q->mq_ops)
> dm_old_start_queue(q);
> else {
> - queue_flag_clear_unlocked(QUEUE_FLAG_STOPPED, q);
> blk_mq_start_stopped_hw_queues(q, true);
> blk_mq_kick_requeue_list(q);
> }
> @@ -98,13 +97,13 @@ void dm_stop_queue(struct request_queue *q)
> {
> if (!q->mq_ops)
> dm_old_stop_queue(q);
> - else {
> - spin_lock_irq(q->queue_lock);
> - queue_flag_set(QUEUE_FLAG_STOPPED, q);
> - spin_unlock_irq(q->queue_lock);
> -
> + else if (!blk_mq_queue_stopped(q)) {
> + /* Wait until dm_mq_queue_rq() has finished. */
> + blk_mq_freeze_queue(q);
> + /* Avoid that requeuing could restart the queue. */
> blk_mq_cancel_requeue_work(q);
> blk_mq_stop_hw_queues(q);
> + blk_mq_unfreeze_queue(q);
> }
> }
>
> @@ -318,13 +317,10 @@ static void dm_old_requeue_request(struct request *rq)
> static void dm_mq_requeue_request(struct request *rq)
> {
> struct request_queue *q = rq->q;
> - unsigned long flags;
>
> blk_mq_requeue_request(rq);
> - spin_lock_irqsave(q->queue_lock, flags);
> - if (!blk_queue_stopped(q))
> - blk_mq_kick_requeue_list(q);
> - spin_unlock_irqrestore(q->queue_lock, flags);
> + WARN_ON_ONCE(blk_mq_queue_stopped(q));
> + blk_mq_kick_requeue_list(q);
> }
>
> static void dm_requeue_original_request(struct mapped_device *md,
> @@ -867,17 +863,6 @@ static int dm_mq_queue_rq(struct blk_mq_hw_ctx *hctx,
> dm_put_live_table(md, srcu_idx);
> }
>
> - /*
> - * On suspend dm_stop_queue() handles stopping the blk-mq
> - * request_queue BUT: even though the hw_queues are marked
> - * BLK_MQ_S_STOPPED at that point there is still a race that
> - * is allowing block/blk-mq.c to call ->queue_rq against a
> - * hctx that it really shouldn't. The following check guards
> - * against this rarity (albeit _not_ race-free).
> - */
> - if (unlikely(test_bit(BLK_MQ_S_STOPPED, &hctx->state)))
> - return BLK_MQ_RQ_QUEUE_BUSY;
> -
> if (ti->type->busy && ti->type->busy(ti))
> return BLK_MQ_RQ_QUEUE_BUSY;
>
> --
> 2.9.3
>
next prev parent reply other threads:[~2016-09-01 3:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-31 22:14 [PATCH 0/9] dm patches for kernel v4.9 Bart Van Assche
2016-08-31 22:15 ` [PATCH 1/9] blk-mq: Introduce blk_mq_queue_stopped() Bart Van Assche
2016-08-31 22:16 ` [PATCH 2/9] dm: Rename a function argument Bart Van Assche
2016-09-01 3:29 ` Mike Snitzer
2016-09-01 14:17 ` Bart Van Assche
2016-08-31 22:16 ` [PATCH 3/9] dm: Introduce signal_pending_state() Bart Van Assche
2016-08-31 22:16 ` [PATCH 4/9] dm: Convert wait loops Bart Van Assche
2016-08-31 22:17 ` [PATCH 5/9] dm: Add two lockdep_assert_held() statements Bart Van Assche
2016-08-31 22:17 ` [PATCH 6/9] dm: Simplify dm_old_stop_queue() Bart Van Assche
2016-08-31 22:17 ` [PATCH 7/9] dm: Mark block layer queue dead before destroying the dm device Bart Van Assche
2016-08-31 22:18 ` [PATCH 8/9] dm: Fix two race conditions related to stopping and starting queues Bart Van Assche
2016-09-01 3:13 ` Mike Snitzer [this message]
2016-09-01 14:23 ` Bart Van Assche
2016-09-01 15:05 ` Mike Snitzer
2016-09-01 15:31 ` Bart Van Assche
2016-09-01 15:50 ` Mike Snitzer
2016-09-01 16:12 ` Mike Snitzer
2016-09-01 17:59 ` Bart Van Assche
2016-09-01 19:05 ` Mike Snitzer
2016-09-01 19:35 ` Mike Snitzer
2016-09-01 20:15 ` Bart Van Assche
2016-09-01 20:33 ` Mike Snitzer
2016-09-01 20:39 ` Bart Van Assche
2016-09-01 20:48 ` Mike Snitzer
2016-09-01 20:52 ` Bart Van Assche
2016-09-01 21:17 ` Mike Snitzer
2016-09-01 22:18 ` Mike Snitzer
2016-09-01 22:22 ` Bart Van Assche
2016-09-01 22:26 ` Mike Snitzer
2016-09-01 23:17 ` Bart Van Assche
2016-09-01 23:47 ` Mike Snitzer
2016-09-02 0:03 ` Bart Van Assche
2016-09-02 15:12 ` Mike Snitzer
2016-09-02 16:10 ` should blk-mq halt requeue processing while queue is frozen? [was: Re: [PATCH 8/9] dm: Fix two race conditions related to stopping and starting queues] Mike Snitzer
2016-09-02 22:42 ` [dm-devel] should blk-mq halt requeue processing while queue is frozen? Bart Van Assche
2016-09-03 0:34 ` Mike Snitzer
2016-09-07 16:41 ` Mike Snitzer
2016-09-13 8:01 ` [dm-devel] " Bart Van Assche
2016-09-13 14:36 ` Mike Snitzer
2016-08-31 22:18 ` [PATCH 9/9] dm path selector: Avoid that device removal triggers an infinite loop Bart Van Assche
2016-09-01 2:49 ` Mike Snitzer
2016-09-01 14:14 ` Bart Van Assche
2016-09-01 15:06 ` Mike Snitzer
2016-09-01 15:22 ` Bart Van Assche
2016-09-01 15:26 ` Mike Snitzer
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=20160901031355.GB4741@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@kernel.dk \
--cc=bart.vanassche@sandisk.com \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).