Re: [PATCH net v3 1/1] ipmr: account multicast table and route memory
From: zihan xi <hidden>
Date: 2026-09-07 12:53:44
Also in:
lkml, stable
On Mon, Sep 7, 2026 at 8:18 PM Ido Schimmel [off-list ref] wrote:
On Mon, Sep 07, 2026 at 08:10:56AM +0000, Zihan Xi wrote:quoted
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.
Will do. v4 rewords this for both IPv4 and IPv6, since mr_table_alloc() is shared.
quoted
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.
Agreed, will mention that in the commit message.
quoted
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.
Will switch Fixes: to these two commits and drop that paragraph.
Please wait 24h before posting another version: https://docs.kernel.org/next/process/maintainer-netdev.html
Will wait 24h before sending v4. Thanks, Zihan Xi
quoted
Cc: stable@vger.kernel.org Reported-by: Vega <redacted> Assisted-by: LLM Signed-off-by: Zihan Xi <redacted>