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
