CVE-2025-68807: block: fix race between wbt_enable_default and IO submission

In the Linux kernel, the following vulnerability has been resolved:

block: fix race between wbtenabledefault and IO submission

When wbtenabledefault() is moved out of queue freezing in elevatorchange(), it can cause the wbt inflight counter to become negative (-1), leading to hung tasks in the writeback path. Tasks get stuck in wbtwait() because the counter is in an inconsistent state.

The issue occurs because wbtenabledefault() could race with IO submission, allowing the counter to be decremented before proper initialization. This manifests as:

rqwait[0]: inflight: -1 haswaiters: True

rwbenabled() checks the state, which can be updated exactly between wbtwait() (rqqosthrottle()) and wbttrack()(rqqostrack()), 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: rqqoswait+0xb4/0x150 wbtwait+0xa9/0x100 rqqosthrottle+0x24/0x40 blkmqsubmitbio+0x672/0x7b0 ...

Fix this by:

1. Splitting wbtenabledefault() into: - wbtenabledefault(): Returns true if wbtinit() should be called - wbtenabledefault(): Wrapper for existing callers (no init) - wbtinitenabledefault(): New function that checks and inits WBT

2. Using wbtinitenabledefault() in blkregisterqueue() to ensure proper initialization during queue registration

3. Move wbtinit() out of wbtenabledefault() which is only for enabling disabled wbt from bfq and iocost, and wbtinit() isn't needed. Then the original lock warning can be avoided.

4. Removing the ELEVATORFLAGENABLEWBTONEXIT 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.