From: David Ahern <dsahern@kernel.org>
To: Antonio Quartulli <antonio@openvpn.net>, Ralf Lici <ralf@mandelbit.com>
Cc: netdev@vger.kernel.org, Sabrina Dubroca <sd@queasysnail.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH net 1/1] ovpn: avoid caching stale IPv6 dst after FIB changes
Date: Tue, 13 Oct 2026 07:52:29 -0600 [thread overview]
Message-ID: <76f16ff2-3102-44e9-b4e0-5818044bbc75@kernel.org> (raw)
In-Reply-To: <375bc468-fb28-4620-a5c8-0f7ba9e693d6@openvpn.net>
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?
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.
prev parent reply other threads:[~2026-10-13 13:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 10:09 [PATCH net 0/1] ovpn: avoid caching stale IPv6 dst after FIB changes Ralf Lici
2026-09-17 10:09 ` [PATCH net 1/1] " Ralf Lici
2026-09-17 19:09 ` David Ahern
2026-09-18 6:51 ` Ralf Lici
2026-09-18 18:42 ` David Ahern
2026-09-18 20:27 ` Ralf Lici
2026-09-28 8:56 ` Ralf Lici
2026-09-29 14:09 ` David Ahern
2026-09-29 15:04 ` Ralf Lici
2026-10-09 0:33 ` Antonio Quartulli
2026-10-13 13:52 ` David Ahern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76f16ff2-3102-44e9-b4e0-5818044bbc75@kernel.org \
--to=dsahern@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=antonio@openvpn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ralf@mandelbit.com \
--cc=sd@queasysnail.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.