Skip to content

Commit 23fffb2

Browse files
committed
io_uring/cancel: re-grab ctx mutex after finishing wait
If we have a signal pending during cancelations, it'll cause the task_work run to return an error. Since we didn't run task_work, the current task is left in TASK_INTERRUPTIBLE state when we need to re-grab the ctx mutex, and the kernel will rightfully complain about that. Move the lock grabbing for the error cases outside the loop to avoid that issue. Reported-by: [email protected] Link: https://lore.kernel.org/io-uring/[email protected]/ Signed-off-by: Jens Axboe <[email protected]>
1 parent 52ea806 commit 23fffb2

File tree

1 file changed

+4
-5
lines changed

1 file changed

+4
-5
lines changed

io_uring/cancel.c

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -288,24 +288,23 @@ int io_sync_cancel(struct io_ring_ctx *ctx, void __user *arg)
288288

289289
ret = __io_sync_cancel(current->io_uring, &cd, sc.fd);
290290

291+
mutex_unlock(&ctx->uring_lock);
291292
if (ret != -EALREADY)
292293
break;
293294

294-
mutex_unlock(&ctx->uring_lock);
295295
ret = io_run_task_work_sig(ctx);
296-
if (ret < 0) {
297-
mutex_lock(&ctx->uring_lock);
296+
if (ret < 0)
298297
break;
299-
}
300298
ret = schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS);
301-
mutex_lock(&ctx->uring_lock);
302299
if (!ret) {
303300
ret = -ETIME;
304301
break;
305302
}
303+
mutex_lock(&ctx->uring_lock);
306304
} while (1);
307305

308306
finish_wait(&ctx->cq_wait, &wait);
307+
mutex_lock(&ctx->uring_lock);
309308

310309
if (ret == -ENOENT || ret > 0)
311310
ret = 0;

0 commit comments

Comments
 (0)