Netdev List
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Sean Anderson <sean.anderson@linux.dev>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 "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
Subject: Re: [PATCH net] selftests: net: csum: Fix checksums for packets with non-zero padding
Date: Mon, 09 Sep 2024 11:06:58 -0400	[thread overview]
Message-ID: <66df0f1276f03_38749294ac@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <9d5bf385-2ef0-435d-b6f9-1de55533653b@linux.dev>

Sean Anderson wrote:
> On 9/6/24 22:05, Willem de Bruijn wrote:
> > 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?
> 
> It's added by the MAC before transmission.
> 
> This is permitted by the standard, but in this case it actually appears
> to be due to the MAC using 32-bit reads for the data and not masking off
> the end. Not sure whether this is a bug in the driver/device, since
> technically we may leak up to 3 bytes of memory.
> 
> That said, it would be a nice enhancement to generate packets with
> non-zero padding as well, since they are an interesting edge case.

Thanks for that context.
 
> > Just trying to understand if this is a bug fix or a new use for
> > csum.c as receiver.
> 
> Bug fix.
> 
> >> 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.
> 
> Yes, as noted above we don't generate packets with differing L3 and L4
> lengths.
> 
> >> Fixes: 91a7de85600d ("selftests/net: add csum offload test")
> >> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>

Reviewed-by: Willem de Bruijn <willemb@google.com>

> >> ---
> >> 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
> 
> OK
> 
> --Sean
> 
> >>  	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-09 15:07 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
2024-09-09 15:02   ` Sean Anderson
2024-09-09 15:06     ` Willem de Bruijn [this message]
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=66df0f1276f03_38749294ac@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