google / alioth / 37217771086

38%

push

github

fix(virtio): drain in-flight io_uring requests before leaving the event loop

When an io_uring worker leaves its event loop on reset or shutdown, it
may still have requests in flight, e.g. a read from a tap device that
waits for the next packet. Dropping the ring does not wait for them:
the kernel cancels them asynchronously, and requests already running
in io-wq threads, e.g. blocking file reads, keep writing into their
buffers. Right after the event loop returns, the worker releases the
memory layout lock, so a pending memory update, e.g. on a VM reboot,
may unmap the memory, or map it again for something else, while the
kernel is still writing into it. Even if the memory stays, the late
writes land in buffers the reset driver no longer owns.

Before returning, the event loop now cancels all requests in the ring
with a single IORING_OP_ASYNC_CANCEL using IORING_ASYNC_CANCEL_ANY
(Linux 5.19+), and reaps completions until no descriptor request is in
flight. The results are discarded since the device is being reset.
Draining also runs if the loop exits with an error.

Some requests cannot be cancelled, e.g. block I/O on a hung NFS mount.
So draining gives up after 5 seconds rather than hang the reset or the
VM shutdown. In that case, or if draining fails, the pages of all
guest memory regions are leaked, so the memory the buffers point into
stays mapped for good.

A descriptor completion is now accounted for before looking up its
queue, so the in-flight count cannot drift and make draining wait for
a request that already completed.

io_uring_drain_test covers a shutdown with a pending read, and
io_uring_drain_cancels_pending_reads the draining itself.

Assisted-by: Antigravity:Claude-Opus-5.5
Signed-off-by: Changyuan Lyu <changyuanl@google.com>

801 of 1638 branches covered (48.9%)

Branch coverage included in aggregate %.

43 of 59 new or added lines in 1 file covered. (72.88%)

5819 of 15545 relevant lines covered (37.43%)

919.53 hits per line