blk-mq: suppress a warning
PATCH 1/1 blk-mq: suppress a warning
The warning is hit when cpu hotplug is running. After scheduler puts a cpu online and before blk-mq mapping reinit, a task can queue a request and run the queue. At that time the cpu isn't in hctx->cpumask, but the cpu is mapped into hctx 0. When the race happens, hctx->cpumask doesn't set the cpu and ctx->index_hw/hctx->nr_ctx isn't correct, but it doesn't cause any problem. So just suppress the warning here.
block/blk-mq.c +1 -1
@@ -724,7 +724,7 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx)LIST_HEAD (rq_list);int queued; -WARN_ON (!cpumask_test_cpu (raw_smp_processor_id (), hctx->cpumask)); +WARN_ON (q->mq_ops->map_queue (q,raw_smp_processor_id ()) != hctx);if (unlikely (test_bit (BLK_MQ_S_STOPPED , &hctx->state)))return ;
Quoted 7 lines · Shaohua Li
The warning is hit when cpu hotplug is running. After scheduler puts a cpu online and before blk-mq mapping reinit, a task can queue a request and run the queue. At that time the cpu isn't in
hctx->cpumask, but the cpu is mapped into hctx 0. When the race happens,hctx->cpumaskdoesn't set the cpu and ctx->index_hw/hctx->nr_ctx isn't correct, but it doesn't cause any problem. So just suppress the warning here.
Thanks Shaohua, I think that is an improvement. Not super fond of having to do an extra map, but it's saner than the CPU test in that it uses the same mechanism to verify it's correct. And we can probably kill this WARN_ON() in a revision or two.