From: Jens Axboe <axboe@kernel.dk>
To: Hengyu Liang <hengyul@cs.unc.edu>
Cc: dw@davidwei.uk, io-uring@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] io_uring/memmap: only charge pinned user memory to RLIMIT_MEMLOCK
Date: Thu, 8 Oct 2026 08:54:33 -0600 [thread overview]
Message-ID: <b5a33433-b0b9-4231-9998-23e2a2202091@kernel.dk> (raw)
In-Reply-To: <20261008045733.773725-1-hengyul@cs.unc.edu>
On 10/7/26 10:57 PM, Hengyu Liang wrote:
> 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>
Thanks for testing!
> 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.
Yes for sure, please feel free to send a patch we can apply on top.
>
> 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
We should still account IORING_MEM_REGION_TYPE_USER, anything that isn't
memcg accounted. I'll take a closer look, but if that isn't the case,
then yes that also needs a followup.
--
Jens Axboe
next prev parent reply other threads:[~2026-10-08 14:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 21:38 [PATCHSET 0/2] Fix memlock account for kernel backed memory Jens Axboe
2026-10-07 21:38 ` [PATCH 1/2] Revert "io_uring/memmap: account the pages a compound region really uses" Jens Axboe
2026-10-07 21:38 ` [PATCH 2/2] io_uring/memmap: only charge pinned user memory to RLIMIT_MEMLOCK Jens Axboe
2026-10-08 4:57 ` Hengyu Liang
2026-10-08 14:54 ` Jens Axboe [this message]
2026-10-08 17:06 ` [PATCH] io_uring: do not charge user provided SQ/CQ rings " Hengyu Liang
2026-10-08 19:11 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5a33433-b0b9-4231-9998-23e2a2202091@kernel.dk \
--to=axboe@kernel.dk \
--cc=dw@davidwei.uk \
--cc=hengyul@cs.unc.edu \
--cc=io-uring@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.