Re: [PATCH] io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK

On 2026-10-06 16:59, Jens Axboe wrote:

On 10/6/26 6:57 AM, hengyul@cs.unc.edu wrote:

quoted

From: Hengyu Liang <redacted>

Commit 8078486e1d53 ("io_uring: use region api for SQ") and commit
81a4058e0cd0 ("io_uring: use region api for CQ") made io_uring_setup()
allocate the rings with io_create_region().

However, io_create_region() charges the memory to RLIMIT_MEMLOCK, and
the rings had been exempt from that limit since commit 26bfa89e25f4
("io_uring: place ring SQ/CQ arrays under memcg memory limits"). As of
now, a user without CAP_IPC_LOCK gets ENOMEM from io_uring_setup() when
their rings exceed the limit, which is 8 MiB by default. PostgreSQL
developers have already hit this in their io_uring tests [1].

The issue can be reproduced with a simple liburing program, run as an
unprivileged user:

     #include <liburing.h>
     #include <stdio.h>

     int main(void)
     {
             static struct io_uring ring[64];
             int i;

             for (i = 0; i < 64; i++)
                     if (io_uring_queue_init(4096, &ring[i], 0) < 0)
                             break;
             printf("%d rings\n", i);
             return 0;
     }

Before those commits (v6.13), it prints "64 rings". After those commits
(v6.14), it prints "21 rings".

This patch makes io_create_region() take the user to charge, and passes
no user for the SQ/CQ rings.

Agree that this is a bug, stricter accounting may break use cases.
However, I think we can solve this simpler, and actually kill more code.
How about something like the below instead? Only apply accounting to
user backed memory, which is how it used to work too. Would be great if
you could take a look and also run your test case against it.

Tested in a VM and confirmed that with the patch below the reproducer
correctly allocates all 64 w/ a 8 MB RLIMIT_MEMLOCK.

This change is really helpful for me as well, thank you for addressing
this Hengyu.