Re: [PATCH] mm/secretmem: properly account locked pages

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Aug 18, 2026 at 02:20:06PM +0900, Daehyeon Ko wrote:
> Thanks for the patch.
>
> I tested this v1 on its stated base with an x86_64 KASAN kernel. The supplied
> selftest passed 6/6 in three boots. Additional fork/unmap and inherited-VMA
> mremap tests also passed.
>
> One question: the inode stores the creator's user_struct, but the fault path
> uses the current task's RLIMIT_MEMLOCK.
>
>   secretmem_init_inode_priv():
>     state->user = get_uid(current_user());
>   __secretmem_account_pages():
>     page_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>
> With A limited to one page and B to four, A created the fd and passed it to B.
> B faulted four pages, after which A got SIGBUS faulting one page on a new fd:
>
>   CROSS_PRINCIPAL receiver_pages=4 creator_fresh_page=0
>
> This seems to charge A's locked_vm using B's limit. Is that intended?

Yup, it's a per-process limit even if the accounting spans multiple
processes.

It'd be incredibly involved to track each resource individually and this is
a trade-off.

In practice people aren't typically varying the limits like this and in any
case, the least surprising behaviour is to adhere to the current process's
limit.

And this is the same solution used everywhere else by io_uring, etc.

>
> Thanks,
> Daehyeon

--
Cheers, Lorenzo