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

[zihan xi]

On Mon, Sep 7, 2026 at 8:18 PM Ido Schimmel <idosch@xxxxxxxxxx> wrote:
>
> 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.

Will do. v4 rewords this for both IPv4 and IPv6, since mr_table_alloc()
is shared.
>
> >
> > 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.
>
> >
> > 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
>
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reported-by: Vega <vega@xxxxxxxxxx>
> > Assisted-by: LLM
> > Signed-off-by: Zihan Xi <zihanx@xxxxxxxxxx>