On Sun, Oct 17, 2021 at 07:50:24PM -0600, Jens Axboe wrote:
> On 10/17/21 7:49 PM, Ming Lei wrote:
> > On Sat, Oct 16, 2021 at 07:35:39PM -0600, Jens Axboe wrote:
> >> We could have a race here, where the request gets freed before we call
> >> into blk_mq_run_hw_queue(). If this happens, we cannot rely on the state
> >> of the request.
> >>
> >> Grab the hardware context before inserting the flush.
> >>
> >> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
> >>
> >> ---
> >>
> >> diff --git a/block/blk-mq.c b/block/blk-mq.c
> >> index 2197cfbf081f..22b30a89bf3a 100644
> >> --- a/block/blk-mq.c
> >> +++ b/block/blk-mq.c
> >> @@ -2468,9 +2468,10 @@ void blk_mq_submit_bio(struct bio *bio)
> >> }
> >>
> >> if (unlikely(is_flush_fua)) {
> >> + struct blk_mq_hw_ctx *hctx = rq->mq_hctx;
> >> /* Bypass scheduler for flush requests */
> >> blk_insert_flush(rq);
> >> - blk_mq_run_hw_queue(rq->mq_hctx, true);
> >> + blk_mq_run_hw_queue(hctx, true);
> >
> > If the request is freed before running queue, the request queue could
> > be released and the hctx may be freed.
>
> No, we still hold a queue enter ref.
But that one is released when rq is freed since ac7c5675fa45 ("blk-mq: allow
blk_mq_make_request to consume the q_usage_counter reference"), isn't
it?
Thanks,
Ming
