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

2026-07-29, 09:20:36 +0200, Ralf Lici wrote:
> ovpn stores the IPv6 route used for UDP transmission in a per-peer dst
> cache. IPv6 dst validation uses a cookie derived from the route itself,
> or, for routes without their own sernum, from the associated fib6 node.
> 
> If the IPv6 FIB changes after ip6_dst_lookup_flow returns but before
> dst_cache_set_ip6 reads the cookie, ovpn can store an old dst with a new
> cookie. Later dst_cache_get_ip6 can then consider that stale dst valid
> because the stored cookie matches the updated fib6 node sernum.
> 
> Sample the IPv6 FIB generation before and after route lookup, and only
> populate ovpn's peer dst cache if the generation did not change while
> the lookup was in flight. Also add a dst_cache helper that stores a
> caller-provided IPv6 cookie, so the cached dst carries the cookie
> sampled from the lookup result instead of one read after a concurrent
> FIB update.
> 
> The current packet may still be transmitted with the route returned by
> the lookup if the FIB changes before TX completion. This patch only
> prevents that potentially stale route from being preserved in ovpn's
> peer dst cache and reused for later packets.
> 
> Fixes: 08857b5ec5d9 ("ovpn: implement basic TX path (UDP)")
> Signed-off-by: Ralf Lici <[email protected]>
> ---
> Changes since v1 https://lore.kernel.org/openvpn-devel/d6c941fe19455b940dd24019e32b121f332fdc95.1785253480.git.ralf@mandelbit.com/
> - Add smp_rmb barriers after the initial generation read and before the
>   final generation read to avoid reordering around the lookup on weakly
>   ordered architectures (Sashiko).
> 
>  drivers/net/ovpn/udp.c  | 50 ++++++++++++++++++++++++++++-------------
>  include/net/dst_cache.h | 13 +++++++++++
>  net/core/dst_cache.c    | 16 +++++++++----
>  3 files changed, 60 insertions(+), 19 deletions(-)

I think you should submit this one to netdev for review (as a patch,
not as part of the next ovpn pull request), since it touches code
outside of ovpn.

I also feel like there should be a better way to do this. Modules
doing their own cookie comparison seems wrong.

-- 
Sabrina