diff options
| author | Jens Axboe <axboe@kernel.dk> | 2026-09-08 17:03:12 +0000 |
|---|---|---|
| committer | Jens Axboe <axboe@kernel.dk> | 2026-09-28 11:47:37 -0600 |
| commit | 044e5f30b3e0efe96dac1b75e15621bfbdb0a767 (patch) | |
| tree | c8636c9ef055df84010d698f162aa6f9bbf021ec /tools/lib/python | |
| parent | fffb79350f9e653a9318bd4de09d98d9cbdbc537 (diff) | |
io_uring/cancel: cancel and wait for all requests on process exit
When a task exits, io_uring only cancels and waits for the few request
types that must not outlive it, and leaves everything else to be torn
down whenever the ring itself goes away. This happens from a kernel
workqueue, and may be some time after the final fput of the ring has
been completed. This sometimes causes application issues, where a task
that was doing IO on a file in /mnt, for example, will leave /mnt busy
for a brief period of time after close(ring_fd) is done.
If the whole thread group is exiting, no thread is left to reap
completions or care about those requests. For this case, tear everything
down. This is basically what exec does today.
Two types of requests are ignored, as they never pin any files and will
always complete on their own. One is armed timeouts, which may still be
required to trigger if a ring is being shared, and the other is SEND_ZC
notifications, which can take almost an unbounded time to complete.
io_uring_try_cancel_requests() now takes flags to manage that behavior.
While in there, fix up the wait loop for the exit case. A task that is
exiting because of a fatal signal still has that signal pending, which
turns the interruptible sleep into a busy loop. Use short
uninterruptible sleeps in that case instead, task_work still gets run in
between.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
