* [PATCH V2 1/2] blk-mq: make sure hctx->next_cpu is set correctly
2018-01-17 16:41 [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug Ming Lei
@ 2018-01-17 16:41 ` Ming Lei
2018-01-17 16:41 ` [PATCH V2 2/2] blk-mq: avoid one WARN_ON in __blk_mq_run_hw_queue to printk Ming Lei
2018-01-17 16:49 ` [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug Jens Axboe
2 siblings, 0 replies; 4+ messages in thread
From: Ming Lei @ 2018-01-17 16:41 UTC (permalink / raw)
To: Jens Axboe, linux-block, Thomas Gleixner
Cc: Christoph Hellwig, jianchao . wang, Christian Borntraeger,
Ming Lei, Stefan Haberland, Christoph Hellwig
When hctx->next_cpu is set from possible online CPUs, there is one
race in which hctx->next_cpu may be set as >= nr_cpu_ids, and finally
break workqueue.
The race can be triggered in the following two sitations:
1) when one CPU is becoming DEAD, blk_mq_hctx_notify_dead() is called
to dispatch requests from the DEAD cpu context, but at that
time, this DEAD CPU has been cleared from 'cpu_online_mask', so all
CPUs in hctx->cpumask may become offline, and cause hctx->next_cpu set
a bad value.
2) blk_mq_delay_run_hw_queue() is called from CPU B, and found the queue
should be run on the other CPU A, then CPU A may become offline at the
same time and all CPUs in hctx->cpumask become offline.
This patch deals with this issue by re-selecting next CPU, and make
sure it is set correctly.
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Stefan Haberland <sth@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: "jianchao.wang" <jianchao.w.wang@oracle.com>
Tested-by: "jianchao.wang" <jianchao.w.wang@oracle.com>
Fixes: 20e4d81393 ("blk-mq: simplify queue mapping & schedule with each possisble CPU")
Signed-off-by: Ming Lei <ming.lei@redhat.com>
---
block/blk-mq.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c376d1b6309a..69e73b4e32f3 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1416,21 +1416,47 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx)
*/
static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)
{
+ bool tried = false;
+
if (hctx->queue->nr_hw_queues == 1)
return WORK_CPU_UNBOUND;
if (--hctx->next_cpu_batch <= 0) {
int next_cpu;
-
+select_cpu:
next_cpu = cpumask_next_and(hctx->next_cpu, hctx->cpumask,
cpu_online_mask);
if (next_cpu >= nr_cpu_ids)
next_cpu = cpumask_first_and(hctx->cpumask,cpu_online_mask);
- hctx->next_cpu = next_cpu;
+ /*
+ * No online CPU is found, so have to make sure hctx->next_cpu
+ * is set correctly for not breaking workqueue.
+ */
+ if (next_cpu >= nr_cpu_ids)
+ hctx->next_cpu = cpumask_first(hctx->cpumask);
+ else
+ hctx->next_cpu = next_cpu;
hctx->next_cpu_batch = BLK_MQ_CPU_WORK_BATCH;
}
+ /*
+ * Do unbound schedule if we can't find a online CPU for this hctx,
+ * and it should only happen in the path of handling CPU DEAD.
+ */
+ if (!cpu_online(hctx->next_cpu)) {
+ if (!tried) {
+ tried = true;
+ goto select_cpu;
+ }
+
+ /*
+ * Make sure to re-select CPU next time once after CPUs
+ * in hctx->cpumask become online again.
+ */
+ hctx->next_cpu_batch = 1;
+ return WORK_CPU_UNBOUND;
+ }
return hctx->next_cpu;
}
--
2.9.5
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH V2 2/2] blk-mq: avoid one WARN_ON in __blk_mq_run_hw_queue to printk
2018-01-17 16:41 [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug Ming Lei
2018-01-17 16:41 ` [PATCH V2 1/2] blk-mq: make sure hctx->next_cpu is set correctly Ming Lei
@ 2018-01-17 16:41 ` Ming Lei
2018-01-17 16:49 ` [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug Jens Axboe
2 siblings, 0 replies; 4+ messages in thread
From: Ming Lei @ 2018-01-17 16:41 UTC (permalink / raw)
To: Jens Axboe, linux-block, Thomas Gleixner
Cc: Christoph Hellwig, jianchao . wang, Christian Borntraeger,
Ming Lei, Stefan Haberland, Christoph Hellwig
We know this WARN_ON is harmless and in reality it may be trigged,
so convert it to printk() and dump_stack() for avoiding to confuse
people.
Also add comment about two releated races here.
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Stefan Haberland <sth@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "jianchao.wang" <jianchao.w.wang@oracle.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
---
block/blk-mq.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 69e73b4e32f3..480fc7623a5e 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1391,9 +1391,27 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx)
/*
* We should be running this queue from one of the CPUs that
* are mapped to it.
+ *
+ * There are at least two related races now between setting
+ * hctx->next_cpu from blk_mq_hctx_next_cpu() and running
+ * __blk_mq_run_hw_queue():
+ *
+ * - hctx->next_cpu is found offline in blk_mq_hctx_next_cpu(),
+ * but later it becomes online, then this warning is harmless
+ * at all
+ *
+ * - hctx->next_cpu is found online in blk_mq_hctx_next_cpu(),
+ * but later it becomes offline, then the warning can't be
+ * triggered, and we depend on blk-mq timeout handler to
+ * handle dispatched requests to this hctx
*/
- WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
- cpu_online(hctx->next_cpu));
+ if (!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
+ cpu_online(hctx->next_cpu)) {
+ printk(KERN_WARNING "run queue from wrong CPU %d, hctx %s\n",
+ raw_smp_processor_id(),
+ cpumask_empty(hctx->cpumask) ? "inactive": "active");
+ dump_stack();
+ }
/*
* We can't run the queue inline with ints disabled. Ensure that
--
2.9.5
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug
2018-01-17 16:41 [PATCH V2 0/2] blk-mq: two patches related with CPU hotplug Ming Lei
2018-01-17 16:41 ` [PATCH V2 1/2] blk-mq: make sure hctx->next_cpu is set correctly Ming Lei
2018-01-17 16:41 ` [PATCH V2 2/2] blk-mq: avoid one WARN_ON in __blk_mq_run_hw_queue to printk Ming Lei
@ 2018-01-17 16:49 ` Jens Axboe
2 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2018-01-17 16:49 UTC (permalink / raw)
To: Ming Lei, linux-block, Thomas Gleixner
Cc: Christoph Hellwig, jianchao . wang, Christian Borntraeger
On 1/17/18 9:41 AM, Ming Lei wrote:
> Hi Jens,
>
> The 1st one fixes one regression caused by 20e4d81393 ("blk-mq: simplify
> queue mapping & schedule with each possisble CPU").
>
> The 2nd one add comments for current two races, and convert the WARN_ON
> into printk(KERN_WARN) with dump_stack() since this warning is harmless.
>
> V2:
> - fix comment and commit log in patch 1
> - use dump_stack() with printk to replace WARN_ON() in patch 2
Applied, thanks.
--
Jens Axboe
^ permalink raw reply [flat|nested] 4+ messages in thread