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

[zihan xi]

On Wed, Sep 9, 2026 at 3:10 PM Ido Schimmel <idosch@xxxxxxxxxx> wrote:
>
> On Tue, Sep 08, 2026 at 11:58:39AM +0000, Zihan Xi wrote:
> > A netadmin in a user+net namespace can create many IPv4 and IPv6
> > multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen
> > id allocates an mr_table via the shared mr_table_alloc(), links it
> > into the per-net list, and leaves it until netns teardown. Those
> > objects were not charged to memcg, so the host unreclaimable slab
> > grows with the table count.
> >
> > 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.
> >
> > Unresolved MFC entries are still allocated from softIRQ with
> > GFP_ATOMIC and are not charged. They expire after 10 seconds and are
> > bounded by the socket receive queue; see commit 0079ad8e8dc3
> > ("ipmr: remove hard code cache_resolve_queue_len limit").
>
> Not worth a v5, just noting in case Sashiko nit picks on it:
>
> Unresolved MFC entries can be allocated from process context and in this
> case they are charged correctly.

Thanks for pointing that out.
>
> >
> > Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables")
> > Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reported-by: Vega <vega@xxxxxxxxxx>
> > Assisted-by: LLM
> > Signed-off-by: Zihan Xi <zihanx@xxxxxxxxxx>
>
> Reviewed-by: Ido Schimmel <idosch@xxxxxxxxxx>

Thanks for the review.

Zihan Xi