Re: [PATCH] blk-mq: prevent unmapped hw queue from being scheduled

From: Jens Axboe
Date: Mon Dec 08 2014 - 23:39:32 EST


On 12/08/2014 05:41 PM, Ming Lei wrote:
On Wed, Dec 3, 2014 at 7:38 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
When one hardware queue has no mapped software queues, it
shouldn't have been scheduled. Otherwise WARNING or OOPS
can triggered.

blk_mq_hw_queue_mapped() helper is introduce for fixing
the problem.

Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxxxxx>
---
block/blk-mq.c | 8 ++++++--
block/blk-mq.h | 5 +++++
2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index c95abc6..c916ad0 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -599,7 +599,7 @@ static void blk_mq_rq_timer(unsigned long priv)
* If not software queues are currently mapped to this
* hardware queue, there's nothing to check
*/
- if (!hctx->nr_ctx || !hctx->tags)
+ if (!blk_mq_hw_queue_mapped(hctx))
continue;

blk_mq_tag_busy_iter(hctx, blk_mq_check_expired, &data);
@@ -819,7 +819,8 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)

void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async)
{
- if (unlikely(test_bit(BLK_MQ_S_STOPPED, &hctx->state)))
+ if (unlikely(test_bit(BLK_MQ_S_STOPPED, &hctx->state) ||
+ !blk_mq_hw_queue_mapped(hctx)))
return;

if (!async) {
@@ -926,6 +927,9 @@ static void blk_mq_delay_work_fn(struct work_struct *work)

void blk_mq_delay_queue(struct blk_mq_hw_ctx *hctx, unsigned long msecs)
{
+ if (unlikely(!blk_mq_hw_queue_mapped(hctx)))
+ return;
+
kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx),
&hctx->delay_work, msecs_to_jiffies(msecs));
}
diff --git a/block/blk-mq.h b/block/blk-mq.h
index d567d52..206230e 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -115,4 +115,9 @@ static inline void blk_mq_set_alloc_data(struct blk_mq_alloc_data *data,
data->hctx = hctx;
}

+static inline bool blk_mq_hw_queue_mapped(struct blk_mq_hw_ctx *hctx)
+{
+ return hctx->nr_ctx && hctx->tags;
+}
+
#endif

Gentle ping...

Picked up for 3.19, sorry for the delay. I'm curious how this queue gets scheduled, though. My worry here would be that we are masking a bug that should be fixed separately.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/