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

[Eric Dumazet]

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?