From: Antoine Tenart <atenart@kernel.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Cc: steffen.klassert@secunet.com, willemdebruijn.kernel@gmail.com,
netdev@vger.kernel.org
Subject: Re: [PATCH net v2 3/4] udp: do not transition UDP fraglist to unnecessary checksum
Date: Tue, 19 Mar 2024 17:01:36 +0100 [thread overview]
Message-ID: <171086409633.4835.11427072260403202761@kwain> (raw)
In-Reply-To: <65f9954c70e28_11543d294f3@willemb.c.googlers.com.notmuch>
Quoting Willem de Bruijn (2024-03-19 14:38:20)
> Antoine Tenart wrote:
> > udp4/6_gro_complete transition fraglist packets to CHECKSUM_UNNECESSARY
> > and sets their checksum level based on if the packet is recognized to be
> > a tunneled one. However there is no safe way to detect a packet is a
> > tunneled one and in case such packet is GROed at the UDP level, setting
> > a wrong checksum level will lead to later errors. For example if those
> > packets are forwarded to the Tx path they could produce the following
> > dump:
> >
> > gen01: hw csum failure
> > skb len=3008 headroom=160 headlen=1376 tailroom=0
> > mac=(106,14) net=(120,40) trans=160
> > shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
> > csum(0xffff232e ip_summed=2 complete_sw=0 valid=0 level=0)
> > hash(0x77e3d716 sw=1 l4=1) proto=0x86dd pkttype=0 iif=12
> > ...
> >
> > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > Signed-off-by: Antoine Tenart <atenart@kernel.org>
>
> The original patch converted to CHECKSUM_UNNECESSARY for a reason.
> The skb->csum of the main gso_skb is not valid?
>
> Should instead only the csum_level be adjusted, to always keep
> csum_level == 0?
The above trace is an ICMPv6 packet being tunneled and GROed at the UDP
level, thus we have:
UDP(CHECKSUM_PARTIAL)/Geneve/ICMPv6(was CHECKSUM_NONE)
csum_level would need to be 1 here; but we can't know that.
There is another issue (no kernel trace): if a packet has partial csum
and is being GROed that information is lost and the packet ends up with
an invalid csum.
Packets with CHECKSUM_UNNECESSARY should end up with the same info. My
impression is this checksum conversion is at best setting the same info
and otherwise is overriding valuable csum information.
Or would packets with CSUM_NONE being GROed would benefit from the
CHECKSUM_UNNECESSARY conversion?
For reference, original commit says:
"""
After validating the csum, we mark ip_summed as
CHECKSUM_UNNECESSARY for fraglist GRO packets to
make sure that the csum is not touched.
"""
But I'm failing to see where that would happen and how the none to
unnecessary conversion would help. WDYT?
Thanks,
Antoine
next prev parent reply other threads:[~2024-03-19 16:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-19 9:31 [PATCH net v2 0/4] gro: various fixes related to UDP tunnels Antoine Tenart
2024-03-19 9:31 ` [PATCH net v2 1/4] udp: do not accept non-tunnel GSO skbs landing in a tunnel Antoine Tenart
2024-03-20 2:41 ` Jakub Kicinski
2024-03-20 11:11 ` Antoine Tenart
2024-03-20 10:34 ` Nikolay Aleksandrov
2024-03-20 11:13 ` Antoine Tenart
2024-03-19 9:31 ` [PATCH net v2 2/4] gro: fix ownership transfer Antoine Tenart
2024-03-19 13:13 ` Willem de Bruijn
2024-03-19 9:31 ` [PATCH net v2 3/4] udp: do not transition UDP fraglist to unnecessary checksum Antoine Tenart
2024-03-19 13:38 ` Willem de Bruijn
2024-03-19 16:01 ` Antoine Tenart [this message]
2024-03-20 13:00 ` Willem de Bruijn
2024-03-20 15:08 ` Antoine Tenart
2024-03-20 20:43 ` Willem de Bruijn
2024-03-21 8:48 ` Antoine Tenart
2024-03-21 12:42 ` Paolo Abeni
2024-03-21 14:58 ` Willem de Bruijn
2024-03-21 17:22 ` Antoine Tenart
2024-03-21 18:13 ` Willem de Bruijn
2024-03-22 10:48 ` Antoine Tenart
2024-03-19 9:31 ` [PATCH net v2 4/4] udp: prevent local UDP tunnel packets from being GROed Antoine Tenart
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=171086409633.4835.11427072260403202761@kwain \
--to=atenart@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
--cc=willemdebruijn.kernel@gmail.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