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 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.

Thanks,
Ming