summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorChris Mason <mason@kernel.org>2026-10-25 20:56:17 +0000
committerJens Axboe <axboe@kernel.dk>2026-10-28 10:50:24 -0600
commitcb0306c52ffae083a86fb283de67875ae7a9500e (patch)
tree7356eb6cf604ceb25efc7e1a4daa1e9942d88e3b /tools/lib/python/kdoc/python_version.py
parent360395e8dbf9d23579f74b84a1af11190813b0f8 (diff)
io_uring/cancel: drop sqd->lock while SQPOLL waits
An exiting SQPOLL thread calls io_uring_cancel_generic() with sqd->lock held, and keeps it across cond_resched() and the sleep until nothing is in flight anymore. A zero-copy send notification can't be canceled and stays pending as long as the peer doesn't read, so the lock is held for as long as a user cares to. io_ring_exit_work() needs it to park the thread, and so do IORING_REGISTER_IOWQ_AFF and IOWQ_MAX_WORKERS. With 64 such rings sharing the thread, every iou_exit slot sleeps on the lock and no ring gets freed for anyone. Drop the lock around cond_resched() and the sleep, like the main loop of the thread does. Each walk of ctx_list is still under one hold, and nothing is kept across the unlock. The thread drops its io-wq, frees its tctx and clears sqd->thread under one hold after the loop, so whoever holds the lock and finds sqd->thread set can still use them. Fixes: 63809137ebb5 ("io_uring: flush notifiers after sendzc") Signed-off-by: Chris Mason <mason@kernel.org> [axboe: adapted to the schedule_timeout() based loop] Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions