Thread (4 messages) flat view 4 messages, 2 authors, 3d ago

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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help