[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240604130527.3597-1-hagarhem@amazon.com>
Date: Tue, 4 Jun 2024 13:05:27 +0000
From: Hagar Hemdan <hagarhem@...zon.com>
To:
CC: Maximilian Heyne <mheyne@...zon.de>, Norbert Manthey <nmanthey@...zon.de>,
Hagar Hemdan <hagarhem@...zon.com>, Jens Axboe <axboe@...nel.dk>, "Pavel
Begunkov" <asml.silence@...il.com>, <io-uring@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: [PATCH] io_uring: fix possible deadlock in io_register_iowq_max_workers()
The io_register_iowq_max_workers() function calls io_put_sq_data(),
which acquires the sqd->lock without releasing the uring_lock.
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
before acquiring sqd->lock"), this can lead to a potential deadlock
situation.
To resolve this issue, the uring_lock is released before calling
io_put_sq_data(), and then it is re-acquired after the function call.
This change ensures that the locks are acquired in the correct
order, preventing the possibility of a deadlock.
Suggested-by: Maximilian Heyne <mheyne@...zon.de>
Signed-off-by: Hagar Hemdan <hagarhem@...zon.com>
---
only compile tested.
---
io_uring/register.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/io_uring/register.c b/io_uring/register.c
index ef8c908346a4..c0010a66a6f2 100644
--- a/io_uring/register.c
+++ b/io_uring/register.c
@@ -355,8 +355,10 @@ static __cold int io_register_iowq_max_workers(struct io_ring_ctx *ctx,
}
if (sqd) {
+ mutex_unlock(&ctx->uring_lock);
mutex_unlock(&sqd->lock);
io_put_sq_data(sqd);
+ mutex_lock(&ctx->uring_lock);
}
if (copy_to_user(arg, new_count, sizeof(new_count)))
@@ -380,8 +382,10 @@ static __cold int io_register_iowq_max_workers(struct io_ring_ctx *ctx,
return 0;
err:
if (sqd) {
+ mutex_unlock(&ctx->uring_lock);
mutex_unlock(&sqd->lock);
io_put_sq_data(sqd);
+ mutex_lock(&ctx->uring_lock);
}
return ret;
}
--
2.40.1
Powered by blists - more mailing lists