Re: [PATCH 2/2] io_uring/memmap: only charge pinned user memory to RLIMIT_MEMLOCK

[Hengyu Liang <hengyul@cs.unc.edu>]

On 10/7/26 3:38 PM, Jens Axboe wrote:
> Charge RLIMIT_MEMLOCK only for regions backed by pinned user memory, which
> is what the limit is for, and leave kernel allocations to memcg. User
> provided ring memory keeps being charged, it is pinned.

Sorry for the late reply, and thanks for picking this up.

I tested both patches on top of v7.3-rc4. The test case from my patch
prints "64 rings" again, kernel allocated buffer rings are fixed as well,
the per-user locked_vm count is balanced after ring create, close and
resize, and the liburing tests give the same results as before, except
that read-before-exit.t passes again with the default limit.

Tested-by: Hengyu Liang <hengyul@cs.unc.edu>

One case is not restored. v6.13 did not charge rings created with
IORING_SETUP_NO_MMAP either. Number of rings created out of 64, as an
unprivileged user with the default 8 MiB limit, 4096 entries each:

                                     v6.13  v7.3-rc4  this series
  io_uring_queue_init()                 64        16           64
  io_uring_queue_init_mem()             64        21           21

PostgreSQL 18 is in the second row. It puts its rings into shared memory
with io_uring_queue_init_mem() whenever liburing has it [1], so I expect
the failure they reported to stay. I have not run PostgreSQL itself.

Would you take a patch on top that leaves the SQ/CQ rings uncharged for
user memory too, as in v6.13? I can send one, or test whatever you prefer.

Also, kernel allocated IORING_REGISTER_MEM_REGION regions are no longer
charged. They have been charged since they were added in v6.14. With the
series a user with an 8 MiB limit can register a 512 MiB one.

[1] https://github.com/postgres/postgres/blob/REL_18_STABLE/src/backend/storage/aio/method_io_uring.c