Hi 在 2026/2/12 16:46, Nilay Shroff 写道: > > 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.
I agree it's not necessary, however I also feel it doesn't matter. > > 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. I don't have preference here, I can do this in the next version. > > For reference, > blk_mq_freeze_queue()/blk_mq_unfreeze_queue() vs > blk_mq_freeze_queue_nomemsave()/blk_mq_unfreeze_queue_nomemrestore() > > Thanks, > --Nilay -- Thansk, Kuai
