Re: [PATCH V2] block: fix race between wbt_enable_default and IO submission

[Jens Axboe <axboe@kernel.dk>]

On 12/17/25 9:41 PM, Caleb Sander Mateos wrote:
> On Wed, Dec 17, 2025 at 7:20 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 12/17/25 8:18 PM, Ming Lei wrote:
>>> On Fri, Dec 12, 2025 at 10:35?PM Ming Lei <ming.lei@redhat.com> wrote:
>>>>
>>>> When wbt_enable_default() is moved out of queue freezing in elevator_change(),
>>>> it can cause the wbt inflight counter to become negative (-1), leading to hung
>>>> tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter
>>>> is in an inconsistent state.
>>>>
>>>> The issue occurs because wbt_enable_default() could race with IO submission,
>>>> allowing the counter to be decremented before proper initialization. This manifests
>>>> as:
>>>>
>>>>   rq_wait[0]:
>>>>     inflight:             -1
>>>>     has_waiters:        True
>>>>
>>>> rwb_enabled() checks the state, which can be updated exactly between wbt_wait()
>>>> (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter
>>>> will become negative.
>>>>
>>>> And results in hung task warnings like:
>>>>   task:kworker/u24:39 state:D stack:0 pid:14767
>>>>   Call Trace:
>>>>     rq_qos_wait+0xb4/0x150
>>>>     wbt_wait+0xa9/0x100
>>>>     __rq_qos_throttle+0x24/0x40
>>>>     blk_mq_submit_bio+0x672/0x7b0
>>>>     ...
>>>>
>>>> Fix this by:
>>>>
>>>> 1. Splitting wbt_enable_default() into:
>>>>    - __wbt_enable_default(): Returns true if wbt_init() should be called
>>>>    - wbt_enable_default(): Wrapper for existing callers (no init)
>>>>    - wbt_init_enable_default(): New function that checks and inits WBT
>>>>
>>>> 2. Using wbt_init_enable_default() in blk_register_queue() to ensure
>>>>    proper initialization during queue registration
>>>>
>>>> 3. Move wbt_init() out of wbt_enable_default() which is only for enabling
>>>>    disabled wbt from bfq and iocost, and wbt_init() isn't needed. Then the
>>>>    original lock warning can be avoided.
>>>>
>>>> 4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling
>>>>    code since it's no longer needed
>>>>
>>>> This ensures WBT is properly initialized before any IO can be submitted,
>>>> preventing the counter from going negative.
>>>>
>>>> Cc: Nilay Shroff <nilay@linux.ibm.com>
>>>> Cc: Yu Kuai <yukuai@fnnas.com>
>>>> Cc: Guangwu Zhang <guazhang@redhat.com>
>>>> Fixes: 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()")
>>>> Signed-off-by: Ming Lei <ming.lei@redhat.com>
>>>> ---
>>>> V2:
>>>>         - explain the race in commit log(Nilay, YuKuai)
>>>
>>> Hi Jens,
>>>
>>> Can you consider this fix for v6.19 if you are fine? Yu Kuai has one
>>> patchset which depends
>>> on this fix.
>>
>> It was queued up on the 12/12, now I'm pondering if the "thanks applied"
>> email never got sent out? In any case, it is in block-6.19.
> 
> I also don't see an email about this series being applied, though it
> appears to be queued in block-6.19:
> https://lore.kernel.org/linux-block/20251212171707.1876250-1-csander@purestorage.com/

Funky! Applied on the same day, so quite possible I messed it up
by flushing the b4 queue or something.

-- 
Jens Axboe