From: "tj@kernel.org" <tj@kernel.org>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "hch@lst.de" <hch@lst.de>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH v2] blk-mq: Fix race between resetting the timer and completion handling
Date: Wed, 7 Feb 2018 12:07:24 -0800 [thread overview]
Message-ID: <20180207200724.GD695913@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <1518027251.2870.53.camel@wdc.com>
Hello, Bart.
On Wed, Feb 07, 2018 at 06:14:13PM +0000, Bart Van Assche wrote:
> When I wrote my comment I was not sure whether or not non-reentrancy is
> guaranteed for work queue items. However, according to what I found in the
> workqueue implementation I think that is guaranteed. So it shouldn't be
> possible that the timer activated by blk_add_timer() gets handled before
> aborted_gstate is reset. But since the timeout handler and completion
Yeah, we're basically single threaded in the timeout path.
> handlers can be executed by different CPUs, shouldn't a memory barrier be
> inserted between the blk_add_timer() call and resetting aborted_gsync to
> guarantee that a completion cannot occur before blk_add_timer() has reset
> RQF_MQ_TIMEOUT_EXPIRED?
Ah, you're right. u64_stat_sync doesn't imply barriers, so we want
something like the following.
diff --git a/block/blk-mq.c b/block/blk-mq.c
index df93102..d6edf3b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -593,7 +593,7 @@ static void blk_mq_rq_update_aborted_gstate(struct request *rq, u64 gstate)
*/
local_irq_save(flags);
u64_stats_update_begin(&rq->aborted_gstate_sync);
- rq->aborted_gstate = gstate;
+ smp_store_release(&rq->aborted_gstate, gstate);
u64_stats_update_end(&rq->aborted_gstate_sync);
local_irq_restore(flags);
}
@@ -605,7 +605,7 @@ static u64 blk_mq_rq_aborted_gstate(struct request *rq)
do {
start = u64_stats_fetch_begin(&rq->aborted_gstate_sync);
- aborted_gstate = rq->aborted_gstate;
+ aborted_gstate = smp_load_acquire(&rq->aborted_gstate);
} while (u64_stats_fetch_retry(&rq->aborted_gstate_sync, start));
return aborted_gstate;
@@ -836,8 +836,8 @@ static void blk_mq_rq_timed_out(struct request *req, bool reserved)
* ->aborted_gstate is set, this may lead to ignored
* completions and further spurious timeouts.
*/
- blk_mq_rq_update_aborted_gstate(req, 0);
blk_add_timer(req);
+ blk_mq_rq_update_aborted_gstate(req, 0);
break;
case BLK_EH_NOT_HANDLED:
break;
next prev parent reply other threads:[~2018-02-07 20:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 1:11 [PATCH v2] blk-mq: Fix race between resetting the timer and completion handling Bart Van Assche
2018-02-07 17:06 ` Tejun Heo
2018-02-07 17:27 ` Bart Van Assche
2018-02-07 17:35 ` tj
2018-02-07 18:14 ` Bart Van Assche
2018-02-07 20:07 ` tj [this message]
2018-02-07 23:48 ` Bart Van Assche
2018-02-08 1:09 ` Bart Van Assche
2018-02-08 15:39 ` tj
2018-02-08 15:40 ` tj
2018-02-08 16:31 ` Bart Van Assche
2018-02-08 17:00 ` tj
2018-02-08 17:10 ` Bart Van Assche
2018-02-08 17:19 ` tj
2018-02-08 17:37 ` Bart Van Assche
2018-02-08 17:40 ` tj
2018-02-08 17:48 ` Bart Van Assche
2018-02-08 17:54 ` tj
2018-02-13 21:20 ` tj
2018-02-14 16:58 ` Bart Van Assche
2018-02-18 13:11 ` tj
2018-02-21 18:53 ` Bart Van Assche
2018-02-21 19:21 ` tj
2018-02-21 22:55 ` Bart Van Assche
2018-02-07 19:03 ` Bart Van Assche
2018-02-07 20:09 ` tj
2018-02-07 21:02 ` Bart Van Assche
2018-02-07 21:40 ` tj
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=20180207200724.GD695913@devbig577.frc2.facebook.com \
--to=tj@kernel.org \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
/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.