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.
Signed-off-by: Shaohua Li <[email protected]>
diff --git a/block/blk-mq.c b/block/blk-mq.c
index ad69ef6..22f314e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -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;
On 07/04/2014 05:26 AM, Shaohua Li wrote:
>
> 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.
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.