From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Sean Anderson <sean.anderson@linux.dev>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Cc: Willem de Bruijn <willemb@google.com>,
linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org,
Sean Anderson <sean.anderson@linux.dev>
Subject: Re: [PATCH net] selftests: net: csum: Fix checksums for packets with non-zero padding
Date: Fri, 06 Sep 2024 22:05:48 -0400 [thread overview]
Message-ID: <66dbb4fcbf560_2af86229423@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <20240906210743.627413-1-sean.anderson@linux.dev>
Sean Anderson wrote:
> Padding is not included in UDP and TCP checksums. Therefore, reduce the
> length of the checksummed data to include only the data in the IP
> payload. This fixes spurious reported checksum failures like
>
> rx: pkt: sport=33000 len=26 csum=0xc850 verify=0xf9fe
> pkt: bad csum
Are you using this test as receiver for other input?
The packet builder in the test doesn't generate these, does it?
Just trying to understand if this is a bug fix or a new use for
csum.c as receiver.
> Technically it is possible for there to be trailing bytes after the UDP
> data but before the Ethernet padding (e.g. if sizeof(ip) + sizeof(udp) +
> udp.len < ip.len). However, we don't generate such packets.
More likely is that L3 and L4 length fields agree, as both are
generated at the sender, but that some trailer is attached in the
network. Such as a timestamp trailer.
> Fixes: 91a7de85600d ("selftests/net: add csum offload test")
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
> Found while testing for this very bug in hardware checksum offloads.
>
> tools/testing/selftests/net/lib/csum.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
> index b9f3fc3c3426..e0a34e5e8dd5 100644
> --- a/tools/testing/selftests/net/lib/csum.c
> +++ b/tools/testing/selftests/net/lib/csum.c
> @@ -654,10 +654,16 @@ static int recv_verify_packet_ipv4(void *nh, int len)
> {
> struct iphdr *iph = nh;
> uint16_t proto = cfg_encap ? IPPROTO_UDP : cfg_proto;
> + uint16_t ip_len;
>
> if (len < sizeof(*iph) || iph->protocol != proto)
> return -1;
>
> + ip_len = ntohs(iph->tot_len);
> + if (ip_len > len || ip_len < sizeof(*iph))
> + return -1;
> +
> + len = ip_len;
> iph_addr_p = &iph->saddr;
> if (proto == IPPROTO_TCP)
> return recv_verify_packet_tcp(iph + 1, len - sizeof(*iph));
> @@ -669,16 +675,22 @@ static int recv_verify_packet_ipv6(void *nh, int len)
> {
> struct ipv6hdr *ip6h = nh;
> uint16_t proto = cfg_encap ? IPPROTO_UDP : cfg_proto;
> + uint16_t ip_len;
nit: payload_len, as it never includes sizeof ipv6hdr
> if (len < sizeof(*ip6h) || ip6h->nexthdr != proto)
> return -1;
>
> + ip_len = ntohs(ip6h->payload_len);
> + if (ip_len > len - sizeof(*ip6h))
> + return -1;
> +
> + len = ip_len;
> iph_addr_p = &ip6h->saddr;
>
> if (proto == IPPROTO_TCP)
> - return recv_verify_packet_tcp(ip6h + 1, len - sizeof(*ip6h));
> + return recv_verify_packet_tcp(ip6h + 1, len);
> else
> - return recv_verify_packet_udp(ip6h + 1, len - sizeof(*ip6h));
> + return recv_verify_packet_udp(ip6h + 1, len);
> }
>
> /* return whether auxdata includes TP_STATUS_CSUM_VALID */
> --
> 2.35.1.1320.gc452695387.dirty
>
next prev parent reply other threads:[~2024-09-07 2:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-06 21:07 [PATCH net] selftests: net: csum: Fix checksums for packets with non-zero padding Sean Anderson
2024-09-07 2:05 ` Willem de Bruijn [this message]
2024-09-09 15:02 ` Sean Anderson
2024-09-09 15:06 ` Willem de Bruijn
2024-09-09 15:09 ` Eric Dumazet
2024-09-09 17:26 ` Willem de Bruijn
2024-09-09 23:51 ` Jakub Kicinski
2024-09-10 1:01 ` Willem de Bruijn
2024-09-10 14:29 ` Sean Anderson
2024-09-10 17:42 ` Willem de Bruijn
2024-09-10 17:52 ` Sean Anderson
2024-09-10 21:01 ` Willem de Bruijn
2024-09-11 0:00 ` patchwork-bot+netdevbpf
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=66dbb4fcbf560_2af86229423@willemb.c.googlers.com.notmuch \
--to=willemdebruijn.kernel@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sean.anderson@linux.dev \
--cc=shuah@kernel.org \
--cc=willemb@google.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