io_uring: check if we need to reschedule during overflow flush

[ Upstream commit eac2ca2d68 ]

In terms of normal application usage, this list will always be empty.
And if an application does overflow a bit, it'll have a few entries.
However, nothing obviously prevents syzbot from running a test case
that generates a ton of overflow entries, and then flushing them can
take quite a while.

Check for needing to reschedule while flushing, and drop our locks and
do so if necessary. There's no state to maintain here as overflows
always prune from head-of-list, hence it's fine to drop and reacquire
the locks at the end of the loop.

Link: https://lore.kernel.org/io-uring/66ed061d.050a0220.29194.0053.GAE@google.com/
Reported-by: syzbot+5fca234bd7eb378ff78e@syzkaller.appspotmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This commit is contained in:
Jens Axboe 2024-09-20 02:51:20 -06:00 committed by Greg Kroah-Hartman
parent 3088483336
commit f4ce3b5d26
1 changed files with 15 additions and 0 deletions

View File

@ -701,6 +701,21 @@ static void __io_cqring_overflow_flush(struct io_ring_ctx *ctx)
memcpy(cqe, &ocqe->cqe, cqe_size); memcpy(cqe, &ocqe->cqe, cqe_size);
list_del(&ocqe->list); list_del(&ocqe->list);
kfree(ocqe); kfree(ocqe);
/*
* For silly syzbot cases that deliberately overflow by huge
* amounts, check if we need to resched and drop and
* reacquire the locks if so. Nothing real would ever hit this.
* Ideally we'd have a non-posting unlock for this, but hard
* to care for a non-real case.
*/
if (need_resched()) {
io_cq_unlock_post(ctx);
mutex_unlock(&ctx->uring_lock);
cond_resched();
mutex_lock(&ctx->uring_lock);
io_cq_lock(ctx);
}
} }
if (list_empty(&ctx->cq_overflow_list)) { if (list_empty(&ctx->cq_overflow_list)) {