Skip to content

Commit 3a07bb1

Browse files
committed
blk-mq: fix potential oops with polling and blk-mq scheduler
If we have a scheduler attached, blk_mq_tag_to_rq() on the scheduled tags will return NULL if a request is no longer in flight. This is different than using the normal tags, where it will always return the fixed request. Check for this condition for polling, in case we happen to enter polling for a completed request. The request address remains valid, so this check and return should be perfectly safe. Fixes: bd166ef ("blk-mq-sched: add framework for MQ capable IO schedulers") Tested-by: Stephen Bates <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
1 parent be56945 commit 3a07bb1

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

block/blk-mq.c

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2928,8 +2928,17 @@ bool blk_mq_poll(struct request_queue *q, blk_qc_t cookie)
29282928
hctx = q->queue_hw_ctx[blk_qc_t_to_queue_num(cookie)];
29292929
if (!blk_qc_t_is_internal(cookie))
29302930
rq = blk_mq_tag_to_rq(hctx->tags, blk_qc_t_to_tag(cookie));
2931-
else
2931+
else {
29322932
rq = blk_mq_tag_to_rq(hctx->sched_tags, blk_qc_t_to_tag(cookie));
2933+
/*
2934+
* With scheduling, if the request has completed, we'll
2935+
* get a NULL return here, as we clear the sched tag when
2936+
* that happens. The request still remains valid, like always,
2937+
* so we should be safe with just the NULL check.
2938+
*/
2939+
if (!rq)
2940+
return false;
2941+
}
29332942

29342943
return __blk_mq_poll(hctx, rq);
29352944
}

0 commit comments

Comments
 (0)