Re: [PATCH] blk-mq: use NOIO context to prevent deadlock during debugfs creation

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

On 2/12/26 1:31 PM, Yu Kuai wrote:
> Creating debugfs entries can trigger fs reclaim, which can enter back
> into the block layer request_queue. This can cause deadlock if the
> queue is frozen.
> 
> Previously, a WARN_ON_ONCE check was used in debugfs_create_files()
> to detect this condition, but it was racy since the queue can be frozen
> from another context at any time.
> 
> Introduce blk_debugfs_mutex_lock()/blk_debugfs_mutex_unlock() helpers
> that combine the debugfs_mutex with memalloc_noio_save()/restore() to
> prevent fs reclaim from triggering block I/O. Replace all raw
> debugfs_mutex lock/unlock pairs with these helpers.

It looks like there are still a few places where ->debugfs_mutex is
taken but the code paths do not enter fs-reclaim. For those cases,
it may not be necessary to wrap the critical section in a NOIO context.

Perhaps it would make sense to provide two separate helper APIs: one
that acquires ->debugfs_mutex and also saves/restores the NOIO context
(using memalloc_noio_save()/restore()), and another that simply acquires
and releases ->debugfs_mutex without entering NOIO. Callers could then 
choose the appropriate helper depending on whether the code path may
trigger fs-reclaim. 

For reference, 
blk_mq_freeze_queue()/blk_mq_unfreeze_queue() vs
blk_mq_freeze_queue_nomemsave()/blk_mq_unfreeze_queue_nomemrestore()

Thanks,
--Nilay