io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return
Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that.
Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run.