From: Kyle Zeng <kylebot@openai.com>
To: netdev-bot+sashiko@kernel.org
Cc: dev@openvswitch.org, netdev@vger.kernel.org, aconole@redhat.com,
echaudro@redhat.com, i.maximets@ovn.org, davem@davemloft.net,
edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: openvswitch: make transport checksums writable
Date: Mon, 9 Nov 2026 21:52:53 -0800 [thread overview]
Message-ID: <avKxNfqPgY6roDJy@com-75606> (raw)
In-Reply-To: <179411065171.994134.7555620955521911858@kernel.org>
On Sun, Nov 08, 2026 at 04:04:11AM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 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 handles every skb_ensure_writable() failure in
> update_ip_l4_checksum() and update_ipv6_checksum()...
>
> --
>
> net: openvswitch: make transport checksums writable
>
> This patch changes the IPv4 and IPv6 address rewrite helpers in Open
> vSwitch. Each L4 checksum update now calls skb_ensure_writable() first,
> instead of checking skb->len. A failure stays nonfatal, and packet
> pointers are reloaded afterwards because the skb head may have moved.
>
> Link: https://lore.kernel.org/r/20261030042304.74291-1-kylebot@openai.com
>
> > diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> > index 12e339cbf7912..fe472e950cb1a 100644
> > --- a/net/openvswitch/actions.c
> > +++ b/net/openvswitch/actions.c
> > @@ -319,20 +319,22 @@ static int pop_nsh(struct sk_buff *skb, struct sw_flow_key *key)
> > return 0;
> > }
> >
> > -static void update_ip_l4_checksum(struct sk_buff *skb, struct iphdr *nh,
> > - __be32 addr, __be32 new_addr)
> > +static void update_ip_l4_checksum(struct sk_buff *skb, __be32 addr,
> > + __be32 new_addr)
> > {
> > - int transport_len = skb->len - skb_transport_offset(skb);
> > + struct iphdr *nh = ip_hdr(skb);
> >
> > if (nh->frag_off & htons(IP_OFFSET))
> > return;
> >
> > if (nh->protocol == IPPROTO_TCP) {
> > - if (likely(transport_len >= sizeof(struct tcphdr)))
> > + if (likely(!skb_ensure_writable(skb, skb_transport_offset(skb) +
> > + sizeof(struct tcphdr))))
> > inet_proto_csum_replace4(&tcp_hdr(skb)->check, skb,
> > addr, new_addr, true);
>
> [Severity: Medium]
> Is it intended that every skb_ensure_writable() failure here is handled
> the same way as a truncated transport header?
>
> skb_ensure_writable() can fail even when the full TCP header is in the
> packet. pskb_may_pull()->__pskb_pull_tail() returns NULL in three cases:
> pskb_expand_head(GFP_ATOMIC) fails, a frag_list skb_clone() fails, or the
> frags are unreadable:
>
> net/core/skbuff.c:__pskb_pull_tail() {
> ...
> if (!skb_frags_readable(skb))
> return NULL;
>
> if (eat > 0 || skb_cloned(skb)) {
> if (pskb_expand_head(skb, 0, eat > 0 ? eat + 128 : 0,
> GFP_ATOMIC))
> return NULL;
> }
> ...
> }
>
> pskb_expand_head(GFP_ATOMIC) can also fail later for a cloned skb.
>
> In those cases the L4 checksum update is skipped. set_ip_addr() still
> updates the IP header checksum and writes the new address:
>
> update_ip_l4_checksum(skb, old_addr, new_addr);
> addr = (__be32 *)(skb_network_header(skb) + addr_offset);
> csum_replace4(&ip_hdr(skb)->check, old_addr, new_addr);
> ...
> *addr = new_addr;
>
> set_ipv6_addr() does the same with memcpy(addr, new_addr, ...). Then
> set_ipv4() or set_ipv6() returns 0.
>
> Would the packet then be forwarded with a rewritten pseudo-header and a
> stale TCP/UDP/ICMPv6 checksum?
>
> With CHECKSUM_NONE or CHECKSUM_COMPLETE the checksum on the wire would be
> wrong. With CHECKSUM_PARTIAL (including GSO), the stale seed in th->check
> or uh->check would give a wrong final checksum for every segment.
>
> The commit message says the reproducer relies on "natural allocation
> pressure". That is the same condition that would make this new
> skb_ensure_writable() call fail.
>
> Other writers in the same file treat this failure as fatal. For example,
> set_tcp():
>
> err = skb_ensure_writable(skb, skb_transport_offset(skb) +
> sizeof(struct tcphdr));
> if (unlikely(err))
> return err;
>
> set_udp() and set_sctp() do the same, so do_execute_actions() drops the
> skb with OVS_DROP_ACTION_ERROR.
>
> Could the update be skipped only when skb->len - skb_transport_offset(skb)
> is smaller than the header size, with the skb_ensure_writable() error
> returned in all other cases? That would need set_ip_addr() and
> set_ipv6_addr() to return int.
>
> The same pattern applies to the UDP branch here, and to the TCP, UDP and
> ICMPv6 branches in update_ipv6_checksum().
>
> [ ... ]
>
> --
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261107040238.27606-1-kylebot%40openai.com
The full-header case is valid: if skb_ensure_writable() fails, the address rewrite can leave the transport checksum or CHECKSUM_PARTIAL seed stale.
But v2 intentionally keeps this failure nonfatal following the earlier review discussion:
https://lore.kernel.org/r/20261030042304.74291-1-kylebot@openai.com
Best,
Kyle
prev parent reply other threads:[~2026-11-10 5:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 4:02 Kyle Zeng
2026-11-08 4:04 ` netdev-bot+sashiko
2026-11-10 5:52 ` Kyle Zeng [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=avKxNfqPgY6roDJy@com-75606 \
--to=kylebot@openai.com \
--cc=aconole@redhat.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®