Re: [PATCH v6 06/13] blk-mq-debugfs: remove blk_mq_debugfs_unregister_rqos()

[Nilay Shroff <nilay@linux.ibm.com>]

On 12/25/25 4:02 PM, Yu Kuai wrote:
> diff --git a/block/blk-rq-qos.c b/block/blk-rq-qos.c
> index d7ce99ce2e80..85cf74402a09 100644
> --- a/block/blk-rq-qos.c
> +++ b/block/blk-rq-qos.c
> @@ -371,8 +371,4 @@ void rq_qos_del(struct rq_qos *rqos)
>  	if (!q->rq_qos)
>  		blk_queue_flag_clear(QUEUE_FLAG_QOS_ENABLED, q);
>  	blk_mq_unfreeze_queue(q, memflags);
> -
> -	mutex_lock(&q->debugfs_mutex);
> -	blk_mq_debugfs_unregister_rqos(rqos);
> -	mutex_unlock(&q->debugfs_mutex);
>  }

This change looks good overall, but I have one comment:

Do we really need to freeze the queue in rq_qos_del() here? Currently,
rq_qos_del() is only called from blk_iocost_init() and blk_iolatency_init(),
both of which run while holding ->freeze_lock. Given this, it seems
unnecessary for rq_qos_del() to freeze and unfreeze the queue again.
Instead, we could remove the freeze/unfreeze logic from rq_qos_del() and
add a WARN_ON() or assertion to ensure that the caller has already frozen
the queue before invoking it.
Moreover, with the current logic, rq_qos_del() may reverse the locking
order between ->rq_qos_mutex and ->freeze_lock if the caller has not
already acquired ->freeze_lock, which could lead to potential lock
ordering issues.

Thanks,
--Nilay