[REGRESSION] io_uring: requests can overtake consecutive drains

[REGRESSION] io_uring: requests can overtake consecutive drains

[Karl Mehltretter]

Commit ecb6817b769f ("io_uring: end the drain when the drain request
completes") lets a request submitted after one drain overtake a second
drain that is still running. This breaks IOSQE_IO_DRAIN ordering for
both standalone and linked drains.

An LLM helped with the review and reproducer.

#regzbot introduced: ecb6817b769fd7d71af2c9f446188649020b2e53

Last good: v7.3, c03c1a14507dfaf8b856c2608f9ac216021fc222
Tested bad: d135ab453a7400a34930bdda1ef4bdc8acfac80e
            (master as of 2026-10-27)

The reproducer uses a default ring and two empty pipes:

  1. Submit P0, a poll on the first pipe.
  2. Submit D1, a drain NOP.
  3. Submit D2, a drain poll on the second pipe.
  4. Wake P0 and wait for D1's CQE.
  5. Submit an ordinary NOP while D2 remains blocked.

The NOP should remain behind D2. Instead, its CQE appears before the
second pipe is woken. The same failure occurs when D2 is linked to a NOP.
An ordinary non-drain poll control still allows the NOP to overtake, as
expected.

Tested with QEMU 11.0.2, arm64 virt/cortex-a57, two vCPUs,
CONFIG_IO_URING=y, and CONFIG_PREEMPT=y:

  v7.3: standalone and linked NOPs stayed blocked for 250 ms
  d135ab453a74: standalone and linked NOPs completed before D2 was woken

No privilege, special device, SQPOLL, or unusual setup flag is required.

Regards,
Karl

Re: [REGRESSION] io_uring: requests can overtake consecutive drains

[Jens Axboe]

On 10/26/26 10:33 PM, Karl Mehltretter wrote:
> Commit ecb6817b769f ("io_uring: end the drain when the drain request
> completes") lets a request submitted after one drain overtake a second
> drain that is still running. This breaks IOSQE_IO_DRAIN ordering for
> both standalone and linked drains.
> 
> An LLM helped with the review and reproducer.

Please have your LLM also make a patch that you can send out,
then you get credit for fixing it as well. Same goes for the
other one you sent out.

> No privilege, special device, SQPOLL, or unusual setup flag is required.

Puzzled why this is necessary to state.

-- 
Jens Axboe