Skip to contentSkip to conversation

blk-mq: suppress a warning

PATCH In review Shaohua Li 2 participants 2 messages Jul 4, 2014 Block layer

lore
Share & tools
lore

Shaohua Li

author
#0 lore raw

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
index ad69ef6..22f314e 100644
@@ -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;
#1 lore raw
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->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.