Re: [PATCH net v3 1/5] ip_tunnel: do not clear the active encap before validating the new one

On Fri, Sep 25, 2026 at 8:53 AM [off-list ref] wrote:

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 (1) · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The patch only fixes the case where
  ip_tunnel_encap_setup()/ip6_tnl_encap_setup() itself fails.

Right, this patch is only about the memset(): a request that
ip[6]_encap_hlen() rejects must leave the tunnel alone.

ipip, sit, ip6_tunnel and ip6_gre changelink handlers setting up
the encapsulation before validating the rest of the request is an older,
separate issue. Fixing it requires staging the encapsulation,
as patches 3 and 4 do for ip_gre, in each of these drivers.
This can be handled separately; v4 states it in the changelog.

Pre-existing issues:
- [Medium] ip_tunnel_encap_setup() and ip6_tnl_encap_setup() update
  t->encap.{type,sport,dport,flags}, t->encap_hlen and t->hlen one field…

Pre-existing indeed, and not specific to the encap fields: the xmit
paths read o_flags,
tun_hlen, needed_headroom and friends locklessly as well.
READ_ONCE()/WRITE_ONCE() annotations (as started by 88b84cae6b94 for IPv4),
or a consistent snapshot of the configuration in the xmit paths, are
net-next material.

In fact, my plan is to convert everything to RCU.

pw-bot: cr