summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorJens Axboe <axboe@kernel.dk>2026-10-30 07:27:28 -0600
committerJens Axboe <axboe@kernel.dk>2026-10-30 07:33:00 -0600
commit22d9db9fd64a493525d692b32c556875b7254665 (patch)
tree71905afa6a3df24ce3ae870c5c915c9172073947 /tools/lib/python/kdoc/python_version.py
parent3e3aebb7570ccdde5cc49c9bfc8fd3a436b71b0c (diff)
io_uring/sqpoll: don't attach to a thread that is canceling
io_sq_offload_create() refuses to attach a ring to an SQPOLL thread that has already gone, by checking sqd->thread under sqd->lock. Since the thread drops the lock while io_uring_cancel_generic() waits for its requests, that check can run while the thread is on its way out and still see it. The new ring is then added to ctx_list, io_uring_setup() succeeds, the thread finishes canceling and exits without ever having looked at the ring, and io_uring_enter() fails with -EOWNERDEAD. Only a thread that exits on a fatal signal can be caught like this, as the stop bit is set once the last ring has let go of the sqd, when no fd is left to attach through. A fatal signal is group wide and attaching needs the same thread group, so the attacher is on its way out as well. Still, make the check see it: set the stop bit before canceling, whatever the reason for the exit, and test it when attaching. Reported-by: Karl Mehltretter <kmehltretter@gmail.com> Fixes: cb0306c52ffa ("io_uring/cancel: drop sqd->lock while SQPOLL waits") 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