Hi Max,

I remembered you reporting this. I think this is a regression introduced
with the scheduling, since ->rqs[] isn't static anymore. ->static_rqs[]
is, but that's not indexable by the tag we find. So I think we need to
guard those with a NULL check. The actual requests themselves are
static, so we know the memory itself isn't going away. But if we race
with completion, we could find a NULL there, validly.

Since you could reproduce it, can you try the below?

diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index d0be72ccb091..b856b2827157 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -214,7 +214,7 @@ static bool bt_iter(struct sbitmap *bitmap, unsigned int 
bitnr, void *data)
                bitnr += tags->nr_reserved_tags;
        rq = tags->rqs[bitnr];
 
-       if (rq->q == hctx->queue)
+       if (rq && rq->q == hctx->queue)
                iter_data->fn(hctx, rq, iter_data->data, reserved);
        return true;
 }
@@ -249,8 +249,8 @@ static bool bt_tags_iter(struct sbitmap *bitmap, unsigned 
int bitnr, void *data)
        if (!reserved)
                bitnr += tags->nr_reserved_tags;
        rq = tags->rqs[bitnr];
-
-       iter_data->fn(rq, iter_data->data, reserved);
+       if (rq)
+               iter_data->fn(rq, iter_data->data, reserved);
        return true;
 }
 

-- 
Jens Axboe

Reply via email to