Netdev List
 help / color / mirror / Atom feed
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
> 



  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