Re: [PATCH net v3 1/1] ipmr: account multicast table and route memory

[Ido Schimmel]

On Mon, Sep 07, 2026 at 08:10:56AM +0000, Zihan Xi wrote:
> A netadmin in a user+net namespace can create many IPv6 multicast
> routing tables with MRT6_TABLE. Each unseen id allocates an mr_table,
> links it into mr6_tables, and leaves it until netns teardown. Those
> objects were not charged to memcg, so the host unreclaimable slab
> grows with the table count.

This reads like an IPv6-only fix, but it also applies to IPv4.
mr_table_alloc() is used by both families. Please reword this paragraph
to reflect that.

> 
> Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the
> IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established
> handling of IP addresses, routes and alternate interface names.

The bots might complain that this doesn't cover unresolved cache entries
that are allocated from softIRQ context. This is correct, but: 1. They
expire after 10 seconds. 2. Bound by the socket's receive queue. See
commit 0079ad8e8dc3 ("ipmr: remove hard code cache_resolve_queue_len
limit"). Worth mentioning in the commit message.

> 
> The first unaccounted IPv6 heap table appeared in commit 4e16880cb422
> ("netns: ip6mr: dynamically allocates vif6_table"), which replaced a
> static vif6_table[] with kcalloc(..., GFP_KERNEL). Commit
> 6bd521433942 ("ipv6: ip6mr: move mroute data into seperate structure")
> only wrapped that already-heap state into mr6_table. Commit
> d1db275dd3f6 ("ipv6: ip6mr: support multiple tables") only expanded
> the table count from 1 to N. IPv6 MFC entries were already unaccounted
> from commit 7bc570c8b4f7 ("[IPV6] MROUTE: Support multicast
> forwarding."); IPv4 ip_mrt_cache is older still.
> 
> Fixes: 4e16880cb422 ("netns: ip6mr: dynamically allocates vif6_table")

I think it makes more sense to blame the commits that allowed user space
to create these tables:

Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables")
Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")

Your reproducer depends on it. And dropping / rewording the last
paragraph.

Please wait 24h before posting another version:

https://docs.kernel.org/next/process/maintainer-netdev.html

> Cc: stable@xxxxxxxxxxxxxxx
> Reported-by: Vega <vega@xxxxxxxxxx>
> Assisted-by: LLM
> Signed-off-by: Zihan Xi <zihanx@xxxxxxxxxx>