Re: [PATCH net 1/1] ovpn: avoid caching stale IPv6 dst after FIB changes

[Ralf Lici <ralf@mandelbit.com>]

Hi David,

On Tue, 13 Oct 2026 07:52:29 -0600, David Ahern <dsahern@kernel.org> wrote:
> On 10/8/26 6:33 PM, Antonio Quartulli wrote:
> > You're right that a cached dst can go stale later and that reuse-time
> > validation handles that. This case is different, because it breaks
> > reuse-time validation.
> > 
> > dst_cache_set_ip6() samples the cookie itself:
> > 
> >         dst_cache_per_cpu_dst_set(idst, dst,
> >                                   rt6_get_cookie(dst_rt6_info(dst)));
> > 
> > rt6_get_cookie() only returns a route-tied value when rt->sernum is
> > non-zero, which happens in ip6_rt_pcpu_alloc() and only for nexthop
> > routes. Everything else reads the current node generation:
> > 
> >         *cookie = READ_ONCE(fn->fn_sernum);
>
> Have you tried setting sernum for all dst_entry when they are created?
>

We have considered that, but the existing field cannot simply be
populated for every dst. A nonzero rt6_info->sernum currently selects
global validation: ip6_dst_check and rt6_get_pcpu_route compare it with
rt_genid_ipv6. It is populated only for external nexthop objects, while
ordinary routes leave it zero and validate through their
fib6_node->fn_sernum, as commit 8f34e53b60b3 ("ipv6: Use global sernum
for dst validation with nexthop objects") explains.

If by setting it for every dst you mean assigning the global
rt_genid_ipv6 value, that would fix the race, but it would turn ordinary
IPv6 dst validation from per-node invalidation into namespace-wide
invalidation, similarly to IPv4.

> This deferred reading of fn_sernum seems to be the problem. fib entries
> have sernum set. dst_entries are created from the fib entries and should
> carry the sernum from the fib entry at that moment.
>

Yes, that is precisely the core issue. The candidate node's fn_sernum
must be sampled as part of route selection and preserved together with
the selected dst, rather than recovered from the dst's fib6_node later.

So there seems to be two possible solutions:

1. add a separate lookup-time cookie to rt6_info, while retaining the
   existing sernum as the external nexthop / global validation marker;
2. have cache-producing lookup APIs return the explicit (dst, cookie)
   pair proposed in the RFC.

The former keeps existing cache users unchanged, but the stored cookie
would have to remain immutable, and reusable per-CPU or exception dsts
would need to be replaced when their node serial changes. The latter
keeps provenance per lookup but requires propagating the pair through
cache-producing callers. What would you prefer?

Thanks!

-- 
Ralf Lici
Mandelbit Srl