io_uring/cancel: re-grab ctx mutex after finishing wait
[ Upstream commit 23fffb2f09ce1145cbd751801d45ba74acaa6542 ] 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: syzbot+7df055631cd1be4586fd@syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/0000000000003a14a905f05050b0@google.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
This commit is contained in:
parent
a02c07b619
commit
a288e98adc
@ -288,24 +288,23 @@ int io_sync_cancel(struct io_ring_ctx *ctx, void __user *arg)
|
|||||||
|
|
||||||
ret = __io_sync_cancel(current->io_uring, &cd, sc.fd);
|
ret = __io_sync_cancel(current->io_uring, &cd, sc.fd);
|
||||||
|
|
||||||
|
mutex_unlock(&ctx->uring_lock);
|
||||||
if (ret != -EALREADY)
|
if (ret != -EALREADY)
|
||||||
break;
|
break;
|
||||||
|
|
||||||
mutex_unlock(&ctx->uring_lock);
|
|
||||||
ret = io_run_task_work_sig(ctx);
|
ret = io_run_task_work_sig(ctx);
|
||||||
if (ret < 0) {
|
if (ret < 0)
|
||||||
mutex_lock(&ctx->uring_lock);
|
|
||||||
break;
|
break;
|
||||||
}
|
|
||||||
ret = schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS);
|
ret = schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS);
|
||||||
mutex_lock(&ctx->uring_lock);
|
|
||||||
if (!ret) {
|
if (!ret) {
|
||||||
ret = -ETIME;
|
ret = -ETIME;
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
|
mutex_lock(&ctx->uring_lock);
|
||||||
} while (1);
|
} while (1);
|
||||||
|
|
||||||
finish_wait(&ctx->cq_wait, &wait);
|
finish_wait(&ctx->cq_wait, &wait);
|
||||||
|
mutex_lock(&ctx->uring_lock);
|
||||||
|
|
||||||
if (ret == -ENOENT || ret > 0)
|
if (ret == -ENOENT || ret > 0)
|
||||||
ret = 0;
|
ret = 0;
|
||||||
|
Loading…
Reference in New Issue
Block a user