Re: [PATCH net 1/1] ipmr: restore a limit for unresolved cache entries

[zihan xi]

On Fri, Aug 28, 2026 at 3:33 PM Eric Dumazet <edumazet@xxxxxxxxxx> wrote:
>
> On Fri, Aug 28, 2026 at 8:52 AM Zihan Xi <zihanx@xxxxxxxxxx> wrote:
> >
> > Unresolved multicast cache entries retain up to four received skbs while
> > waiting for userspace to install an MFC route.  The cache entry count was
> > tracked but no longer bounded, so a stream of distinct source and group
> > pairs could retain packet memory until the system ran out of memory.
> >
> > Restore the unresolved-entry limit for both IPv4 and IPv6 multicast
> > routing.  Reject new cache entries once the limit is reached while keeping
> > existing entries available for normal route resolution.
> >
> > Fixes: 0079ad8e8dc3 ("ipmr: remove hard code cache_resolve_queue_len limit")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Reported-by: Vega <vega@xxxxxxxxxx>
> > Assisted-by: Codex:gpt-5.4
> > Signed-off-by: Zihan Xi <zihanx@xxxxxxxxxx>
> > ---
> >  include/linux/mroute_base.h | 3 +++
> >  net/ipv4/ipmr.c             | 6 ++++++
> >  net/ipv6/ip6mr.c            | 5 +++++
> >  3 files changed, 14 insertions(+)
> >
> > diff --git a/include/linux/mroute_base.h b/include/linux/mroute_base.h
> > index 4d55827e9705..af9247bb3f4d 100644
> > --- a/include/linux/mroute_base.h
> > +++ b/include/linux/mroute_base.h
> > @@ -224,6 +224,9 @@ struct mr_table_ops {
> >         void *cmparg_any;
> >  };
> >
> > +/* Bound unresolved MFC entries and their queued skbs. */
> > +#define MFC_UNRES_QUEUE_LEN_MAX        10
>
> Wasn't this very very very small limit a reported problem in the past?
>
> Nothing will prevent an OOM to happen, even if you set the limit to 1
>
> If panic_on_oom is set, it seems to me that this is working as intended.
>
> If we want to silence the OOM, just change ipmr_cache_alloc_unres()
> to add a __GFP_NOWARN?

Hi Eric,

You are right. I missed the rationale for 0079ad8e8dc3 and the
earlier report that the fixed limit caused problems on busy networks.

The reproducer was run with vm.panic_on_oom=2. It therefore only shows
the expected result of forcing a panic on generic memory exhaustion; it
does not justify reintroducing a per-table limit.

Please disregard this series. I will not post a v2.

Thanks,
Zihan