Re: [PATCH net 1/2] wireguard: account peer and allowedips allocations to memcg

[alex@badcode.im]

Yes, it is the documented expectation for long-lived objects whose
allocation userspace can trigger. 
Documentation/core-api/memory-allocation.rst
says:

     Untrusted allocations triggered from userspace should be a subject
     of kmem accounting and must have __GFP_ACCOUNT bit set.

Most hardware drivers don't need it because their allocations are sized
by the hardware, not by userspace. Virtual devices configured over
netlink from inside a user namespace are a different case, and the core
stack has been converted for that reason. For example:

     6126891c6d4f ("memcg: enable accounting for IP address and 
routing-related objects")
     c948f51c1654 ("memcg: enable accounting for net_device and Tx/Rx 
queues")
     a89893dd7b08 ("memcg: enable accounting for VLAN group array")
     961c6136359e ("net: enable memcg accounting for veth queues")
     33758c891479 ("memcg: enable accounting for nft objects")

and more recently:

     1beb81947eb4 ("net/sched: account classifier filter allocations to 
memcg")
     b0057c68df71 ("xsk: account ring allocations to memcg")

The fib_trie, ip6_fib and ip6 dst caches are created with SLAB_ACCOUNT,
and the netdev queues and VLAN array use GFP_KERNEL_ACCOUNT. The first
commit describes the same situation as here: a netadmin inside a
container adds many addresses/routes and makes the kernel allocate
unaccounted long-lived memory. WireGuard peers and allowed IPs are the
same kind of object, so they should be charged to the same memcg.

There is no functional change unless a memcg limit is set. Then the
configuring process gets -ENOMEM (or the memcg OOM killer runs) instead
of the allocations silently going past the limit.

Thanks,
Alexander

-------- Исходное сообщение --------
Тема: Re: [PATCH net 1/2] wireguard: account peer and allowedips 
allocations to memcg
Дата: 10.11.2026 16:57
От: "Jason A. Donenfeld" <Jason@zx2c4.com>
Кому: Alexander Ildiyarov <alex@badcode.im>

On Thu, Nov 05, 2026 at 05:10:05PM +0300, Alexander Ildiyarov wrote:
> Peers, allowed IP trie nodes, the per-peer dst_cache and the per-device
> hashtables are all allocated in the context of the process that
> configures the device over netlink, but none of these allocations are
> charged to that process's memory cgroup: the wg_peer and 
> allowedips_node
> caches are created without SLAB_ACCOUNT, and the hashtables and
> dst_cache use plain GFP_KERNEL.
> 
> The amount of memory is bounded only by MAX_PEERS_PER_DEVICE (2^20) per
> device, with no limit on the number of devices or on the number of
> allowed IPs per peer. Since WG_CMD_SET_DEVICE uses GENL_UNS_ADMIN_PERM,
> any user who can create a user and network namespace can do this, and
> thereby escape the memory limits of the cgroup it runs in.
> 
> For example, a process in a cgroup with memory.max=64M that adds 100000
> peers with 20 /128 allowed IPs each grows Slab by ~790 MiB, yet the
> cgroup's memory.current stays below 1 MiB and its memory limit is never
> hit.
> 
> Fix this by creating the two caches with SLAB_ACCOUNT and using
> GFP_KERNEL_ACCOUNT for the hashtables and the dst_cache. The keypair
> allocations are left alone, as they happen from the handshake worker 
> and
> are bounded to three per peer.

I wasn't aware of this trick, I think mostly because most drivers don't
use this. Does any other part of the networking stack do this? Is this a
normal thing?