Re: [PATCH] blk-iocost: fix the lock order in ioc_cost_model_write()

[Tejun Heo <tj@kernel.org>]

Hello, Tao.

On Thu, Nov 12, 2026 at 12:21:37AM +0800, Tao Cui wrote:
> The inversion cannot currently deadlock because blk_mq_freeze_queue()
> is in a noio scope since 1e1a9cecfa ("block: force noio scope in
> blk_mq_freeze_queue"), so a caller freezing a queue cannot recurse
> into the frozen queue through reclaim. Holding the mutex across
> the freeze needlessly serializes config writers behind it and
> leaves two different orderings in the same file.

There is no deadlock here to begin with, and the noio scope isn't why.
Freezing is counted and doesn't exclude other freezers, and a freeze only
waits for in-flight IOs to drain, none of which takes rq_qos_mutex. The
patch doesn't make the ordering consistent either. blk_iocost_init() still
freezes under the mutex through rq_qos_add() and blkcg_activate_policy(),
and so do blk_throtl_init() and blk_iolatency_init().

> +	mutex_unlock(&q->rq_qos_mutex);
>  	memflags = blk_mq_freeze_queue(q);
> +	mutex_lock(&q->rq_qos_mutex);

This lets the disk be deleted in the middle. @ioc was looked up before the
unlock and rq_qos_exit() can tear it down before the mutex is retaken.
With a delay added after the unlock and a null_blk device deleted during
it, the write goes on to use the ioc after ioc_rqos_exit() and KASAN
reports use-after-free in blk_mq_quiesce_queue() called from
ioc_cost_model_write().

So, this fixes nothing and adds a bug.

Separately, ioc_qos_write() already has the same window. It retakes the
mutex without rechecking disk_live(), so with the disk deleted in between,
it initializes iocost on the dead disk and hits the same use-after-free.
That's the part which needs fixing.

Thanks.

--
tejun