[PATCH 4/4] blk-mq: use blk_queue_enter/exit to protect debugfs file creation

[Yu Kuai]

Hi,

在 2026/2/11 15:20, Nilay Shroff 写道:
>
> On 2/9/26 1:59 PM, Yu Kuai wrote:
>> diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
>> index faeaa1fc86a7..03583d0d3972 100644
>> --- a/block/blk-mq-debugfs.c
>> +++ b/block/blk-mq-debugfs.c
>> @@ -613,11 +613,6 @@ static void debugfs_create_files(struct request_queue *q, struct dentry *parent,
>>   				 const struct blk_mq_debugfs_attr *attr)
>>   {
>>   	lockdep_assert_held(&q->debugfs_mutex);
>> -	/*
>> -	 * Creating new debugfs entries with queue freezed has the risk of
>> -	 * deadlock.
>> -	 */
>> -	WARN_ON_ONCE(q->mq_freeze_depth != 0);
>>   	/*
>>   	 * debugfs_mutex should not be nested under other locks that can be
>>   	 * grabbed while queue is frozen.
>> @@ -628,9 +623,19 @@ static void debugfs_create_files(struct request_queue *q, struct dentry *parent,
>>   	if (IS_ERR_OR_NULL(parent))
>>   		return;
>>   
>> +	/*
>> +	 * Avoid creating debugfs files while the queue is frozen, wait for
>> +	 * the queue to be unfrozen and prevent new freeze while creating
>> +	 * debugfs files.
>> +	 */
>> +	if (blk_queue_enter(q, 0))
>> +		return;
>> +
>>   	for (; attr->name; attr++)
>>   		debugfs_create_file_aux(attr->name, attr->mode, parent,
>>   				    (void *)attr, data, &blk_mq_debugfs_fops);
>> +
>> +	blk_queue_exit(q);
>>   }
>>   
>>   void blk_mq_debugfs_register(struct request_queue *q)
> I also noticed that we use other debugfs helpers such as debugfs_create_dir()
> from some block paths, which could run into the same fs-reclaim recursion issue.
> So we may need to consider those call sites as well to ensure consistent handling.

Yes, sounds correct.

>
> On another note, instead of waiting for queue to be unfreezed, does it makes sense to
> wrap the debugfs code under NOIO context (as Christoph pointed in another thread)?
> IMO, if fs-reclaim recursion is the only issue here we would be better off using
> NOIO context instead of blocking for queue to be unfrozen from other contexts.

I can try this. So far, debugfs_mutex related deadlocks are related to fs-reclaim,
although I'm not that confident there won't be any other  implicit dependency.
Meanwhile, looks like the previous patches for nvme targets are not necessary anymore.

> Thanks,
> --Nilay
>
-- 
Thansk,
Kuai