[PATCH 1/1] io_uring: delay sqarray static branch disablement

[PATCH 1/1] io_uring: delay sqarray static branch disablement

[Pavel Begunkov]

io_key_has_sqarray static branch can be easily switched
on/off by the user. Prevent abuse and defer for a bit when it's
disabled.

Fixes: 9b296c625ac1d ("io_uring: static_key for !IORING_SETUP_NO_SQARRAY")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 io_uring/io_uring.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 3a2753f6b444..1e627b7a2f3a 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -119,7 +119,7 @@
 static void io_queue_sqe(struct io_kiocb *req, unsigned int extra_flags);
 static void __io_req_caches_free(struct io_ring_ctx *ctx);
 
-static __read_mostly DEFINE_STATIC_KEY_FALSE(io_key_has_sqarray);
+static __read_mostly DEFINE_STATIC_KEY_DEFERRED_FALSE(io_key_has_sqarray, HZ);
 
 struct kmem_cache *req_cachep;
 static struct workqueue_struct *iou_wq __ro_after_init;
@@ -1978,7 +1978,7 @@ static bool io_get_sqe(struct io_ring_ctx *ctx, const struct io_uring_sqe **sqe)
 	unsigned mask = ctx->sq_entries - 1;
 	unsigned head = ctx->cached_sq_head++ & mask;
 
-	if (static_branch_unlikely(&io_key_has_sqarray) &&
+	if (static_branch_unlikely(&io_key_has_sqarray.key) &&
 	    (!(ctx->flags & IORING_SETUP_NO_SQARRAY))) {
 		head = READ_ONCE(ctx->sq_array[head]);
 		if (unlikely(head >= ctx->sq_entries)) {
@@ -2173,7 +2173,7 @@ static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)
 	io_rings_free(ctx);
 
 	if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
-		static_branch_dec(&io_key_has_sqarray);
+		static_branch_slow_dec_deferred(&io_key_has_sqarray);
 
 	percpu_ref_exit(&ctx->refs);
 	free_uid(ctx->user);
@@ -2951,7 +2951,7 @@ static __cold int io_uring_create(struct io_ctx_config *config)
 	ctx->clock_offset = 0;
 
 	if (!(ctx->flags & IORING_SETUP_NO_SQARRAY))
-		static_branch_inc(&io_key_has_sqarray);
+		static_branch_deferred_inc(&io_key_has_sqarray);
 
 	if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) &&
 	    !(ctx->flags & IORING_SETUP_IOPOLL))
-- 
2.52.0

Re: [PATCH 1/1] io_uring: delay sqarray static branch disablement

[Jens Axboe]

On 2/15/26 2:29 PM, Pavel Begunkov wrote:
> io_key_has_sqarray static branch can be easily switched
> on/off by the user. Prevent abuse and defer for a bit when it's
> disabled.

Can we get something in here for the reason for why the change
is being made? The commit message really doesn't explain any
of this.

-- 
Jens Axboe

Re: [PATCH 1/1] io_uring: delay sqarray static branch disablement

[Pavel Begunkov]

On 2/15/26 21:48, Jens Axboe wrote:
> On 2/15/26 2:29 PM, Pavel Begunkov wrote:
>> io_key_has_sqarray static branch can be easily switched
>> on/off by the user. Prevent abuse and defer for a bit when it's
>> disabled.
> 
> Can we get something in here for the reason for why the change
> is being made? The commit message really doesn't explain any
> of this.

It appeared to be pretty self-explanatory, I can expand, but in
short you can spam with

while (1) {
	create_ring_with_sq_array();
	kill_ring();
}

and each iteration it'll be patching kernel code, and that
can be very disruptive for the entire system depending on arch
and how removal is synchronized.

-- 
Pavel Begunkov

Re: [PATCH 1/1] io_uring: delay sqarray static branch disablement

[Jens Axboe]

On 2/15/26 2:56 PM, Pavel Begunkov wrote:
> On 2/15/26 21:48, Jens Axboe wrote:
>> On 2/15/26 2:29 PM, Pavel Begunkov wrote:
>>> io_key_has_sqarray static branch can be easily switched
>>> on/off by the user. Prevent abuse and defer for a bit when it's
>>> disabled.
>>
>> Can we get something in here for the reason for why the change
>> is being made? The commit message really doesn't explain any
>> of this.
> 
> It appeared to be pretty self-explanatory, I can expand, but in
> short you can spam with

It really wasn't! It says "prevent abuse" but is not specific on what
kind of abuse this is at all.

> while (1) {
>     create_ring_with_sq_array();
>     kill_ring();
> }
> 
> and each iteration it'll be patching kernel code, and that
> can be very disruptive for the entire system depending on arch
> and how removal is synchronized.

OK, so that's the abuse being referred to. I could surely find
out by just checking static_branch_slow_dec_deferred() and
friends, but a commit message should stand by itself and not
need that kind of discovery.

Can you just send a v2 with an updated commit message, please?

-- 
Jens Axboe