Re: [PATCH v7 09/16] blk-throttle: fix possible deadlock for fs reclaim under rq_qos_mutex

[Ming Lei <ming.lei@redhat.com>]

On Fri, Jan 09, 2026 at 10:22:27AM +0800, Yu Kuai wrote:
> Hi,
> 
> 在 2026/1/9 10:18, Ming Lei 写道:
> > On Fri, Jan 09, 2026 at 12:56:33AM +0800, Yu Kuai wrote:
> >> Hi,
> >>
> >> 在 2026/1/7 20:04, Ming Lei 写道:
> >>> On Wed, Dec 31, 2025 at 04:51:19PM +0800, Yu Kuai wrote:
> >>>> blk_throtl_init() can be called with rq_qos_mutex held from blkcg
> >>>> configuration, and fs reclaim can be triggered because GFP_KERNEL is used
> >>>> to allocate memory. This can deadlock because rq_qos_mutex can be held
> >>>> with queue frozen.
> >>>>
> >>>> Fix the problem by using blkg_conf_open_bdev_frozen(), also remove
> >>>> useless queue frozen from blk_throtl_init().
> >>>>
> >>>> Signed-off-by: Yu Kuai <yukuai@fnnas.com>
> >>>> ---
> >>> I think this patch goes toward wrong direction by enlarging queue freeze
> >>> scope, and blkg_conf_prep() may run into percpu allocation, then new
> >>> lockdep warning could be triggered.
> >>>
> >>> IMO, we should try to reduce blkg_conf_open_bdev_frozen() uses, instead of
> >>> adding more.
> >> Fortunately, blk_throtl_init() doesn't have percpu allocation, so this is
> >> safe now. Unfortunately, blk-iocost and blk-iolatency do have percpu allocation
> >> and they're already problematic for a long time. The queue is already frozen from
> >> blkcg_activate_policy() and then the pd_alloc_fn() will try percpu allocation.
> >>
> >> To be honest, I feel it's too complicated to move all the percpu allocation out of
> >> queue frozen, will it be possible to fix this the other way by passing another gfp
> >> into pcpu_alloc_noprof() that it'll be atomic to work around the pcpu_alloc_mutex.
> > The first question is why blkg_conf_open_bdev_frozen() is used by io-cost
> > only? I hope it can be removed, then the dependency against percpu
> > allocation can be killed.
> 
> Even if blkg_conf_open_bdev_frozen() is removed, as I said above, blkcg_activate_poilcy()
> still freeze queue, and later pd_alloc_fn() will still run into percpu allocation with
> queue frozen, so I think problem still stands.

That is one local blkcg_activate_poilcy() issue, which can be solved with your approach
by moving pol->pd_alloc_fn() out of queue freeze.

Thanks,
Ming