Hi,

在 2026/2/11 15:20, Nilay Shroff 写道:

On 2/9/26 1:59 PM, Yu Kuai wrote:

quoted

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