Re: [PATCH net v3 1/1] xsk: account ring allocations to memcg

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 07/31, Zihan Xi wrote:
> AF_XDP rings are allocated from setsockopt() and can be mapped into user
> space.  The shared xskq_create() helper allocates the ring backing memory,
> but the user-controlled and long-lived allocation is not charged as kmem
> to the allocating memory cgroup.
> 
> The current implementation uses vmalloc_user(), which allocates the
> backing pages with GFP_KERNEL | __GFP_ZERO.  Use the same VM_USERMAP
> vmalloc path, but pass GFP_KERNEL_ACCOUNT so the ring backing pages are
> attributed to memcg/kmem and can be constrained by existing cgroup memory
> limits.  This keeps the existing zeroing and mmap semantics while avoiding
> AF_XDP-specific optmem or RLIMIT_MEMLOCK accounting.
> 
> Fixes: 423f38329d26 ("xsk: add umem fill queue support and mmap")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Zihan Xi <zihanx@nebusec.ai>
> ---
> changes in v3:
>   - drop the v2 RLIMIT_MEMLOCK / user->locked_vm accounting approach
>     after review feedback
>   - switch the AF_XDP ring backing allocation to the memcg/kmem model by
>     using a VM_USERMAP vmalloc path with GFP_KERNEL_ACCOUNT
>   - include <asm/shmparam.h> explicitly for SHMLBA, matching the
>     vmalloc implementation's dependency
>   - retarget Fixes to 423f38329d26, the original mmapable queue
>     allocation that introduced the missing accounting root-cause fact
>   - v2 Link: https://lore.kernel.org/all/20260730153832.11238-1-zihanx@nebusec.ai/
> changes in v2:
>   - replace the socket optmem limit proposal with RLIMIT_MEMLOCK /
>     user->locked_vm accounting via mm_account_pinned_pages()
>   - drop the earlier socket/pool lifetime coupling changes and keep the
>     final code diff limited to xsk_queue.c and xsk_queue.h
>   - retarget Fixes to 423f38329d26, the original mmapable queue
>     allocation that introduced the missing resource boundary
>   - v1 Link: https://lore.kernel.org/all/cover.1785313094.git.zihanx@nebusec.ai/
>  net/xdp/xsk_queue.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

Acked-by: Stanislav Fomichev <sdf@fomichev.me>

From Documentation/core-api/memory-allocation.rst:

  * Untrusted allocations triggered from userspace should be a subject
    of kmem accounting and must have ``__GFP_ACCOUNT`` bit set. There
    is the handy ``GFP_KERNEL_ACCOUNT`` shortcut for ``GFP_KERNEL``
    allocations that should be accounted.

I don't like that we are calling (seemingly) low level
__vmalloc_node_range, but commit 041de93ff86f ("mm: remove
vmalloc_user_node_flags") removed the previous wrapper and open-coded
it in bpf verifier, so I'm assuming calling __vmalloc_node_range here
is ok as well.