Re: [PATCH net v4] net/packet: account user-triggered allocations to memcg

[Willem de Bruijn]

On Sun, Nov 1, 2026 at 4:50 AM Ahmad AG <ahmadag1001@xxxxxxxxx> wrote:
>
> A packet socket makes allocations whose size or count its user chooses
> without charging them to the user's memory cgroup: the blocks and block
> array of a PACKET_RX_RING or PACKET_TX_RING ring and the rx_owner_map
> of a TPACKET_V1/V2 RX ring, the PACKET_FANOUT group (about 1 MB with
> max_num_members = 65536), and one packet_mclist per
> PACKET_ADD_MEMBERSHIP entry. CAP_NET_RAW in a user namespace is enough
> to pin memory far beyond memory.max this way.
>
> Allocate them with GFP_KERNEL_ACCOUNT, as the AF_XDP rings do since
> commit b0057c68df71 ("xsk: account ring allocations to memcg"), and with
> __GFP_NOWARN where the size comes from user space, so that a ring or
> group that does not fit prints no allocation warning. Fixed-size
> per-socket state is left unaccounted.

That commit was sent without a fixes tag, probably to next.
As this change can cause regressions, it seems correct to send it to net-next,
or to net, but without stable. As the patch already suggests with noautosel.

> Reproducer, as uid 1000 in a memory cgroup with memory.max 16M, after
> unshare(CLONE_NEWUSER | CLONE_NEWNET): open 64 AF_PACKET sockets, give
> each a TPACKET_V2 RX ring of 8 blocks of 1 MB, mmap the rings and touch
> every block. MemFree drops by 526052 KB while memory.current grows by
> 1280 KB. 256 fanout groups with max_num_members = 65536 (265144 KB used,
> 512 KB charged) and 100 sockets with 2000 PACKET_MR_PROMISC entries each
> on lo (45220 KB used, 124 KB charged) behave the same. With this change
> all three are stopped by the cgroup's OOM killer. psock_fanout,
> psock_tpacket and psock_snd.sh pass before and after. Found by code
> inspection with the help of an LLM and reproduced on an unmodified
> kernel without error injection; tested in a QEMU guest with KASAN on
> net.

Can drop this iff respinning, or move below three-dash line.

> The ring pages and rx_owner_map were never charged, the rest not since
> commit a9bb7e620efd ("memcg: only account kmem allocations marked as
> __GFP_ACCOUNT"). The Fixes commit let the user size the fanout array.
>
> Fixes: 9c661b0b8544 ("net/packet: make packet_fanout.arr size configurable up to 64K")
> Cc: <stable+noautosel@xxxxxxxxxx> # changes memcg charging of existing packet rings; not stable material
> Signed-off-by: Ahmad AG <ahmadag1001@xxxxxxxxx>

Reviewed-by: Willem de Bruijn <willemb@xxxxxxxxxx>
> ---
> Tool use: an LLM coding assistant (Claude Code) found the missing
> charges by code inspection, drafted the patch, the test program and this
> message, and ran the tests in the QEMU guest; I reviewed every hunk, the
> results and this message before sending.
>
> v4:
>   - trim the commit message
>   - add __GFP_NOWARN to the fanout group allocation
>   - use __vcalloc() for the vmalloc fallback and bitmap_zalloc() for
>     rx_owner_map

Agreed on the response to the bot: some allocations are purposely skipped.

If a respin is needed, worthwhile to capture that choice explicitly in
the commit
message.