consider two scenarios, where process a sends raw ethernet frames containing UDP packets to b
I) process a --> veth --> process b II) process a -> eth -> wire -> eth -> process b I believe (I) is the simplest setup we can create that will replicate this bug. If process a sends frames that contain UDP packets to process b, what is the behaviour we want if the UDP packet *has an incorrect checksum*? It seems to me that I and II should have identical behaviour, and I would think that (II) would not deliver the packets to the application. In (I) with Cong's patch would we be delivering corrupt UDP packets to process b despite an incorrect checksum in (I)? If so, I would argue that this patch isn't right. On Fri, Mar 25, 2016 at 4:56 PM, Ben Greear <gree...@candelatech.com> wrote: > On 03/24/2016 10:33 PM, Cong Wang wrote: > >> Here we go: >> >> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c >> index 1ecfa71..ab66080 100644 >> --- a/net/packet/af_packet.c >> +++ b/net/packet/af_packet.c >> @@ -1925,6 +1925,7 @@ static int packet_sendmsg_spkt(struct socket >> *sock, struct msghdr *msg, >> goto out_unlock; >> } >> >> + skb->ip_summed = CHECKSUM_UNNECESSARY; >> skb->protocol = proto; >> skb->dev = dev; >> skb->priority = sk->sk_priority; >> @@ -2496,6 +2497,7 @@ static int tpacket_fill_skb(struct packet_sock >> *po, struct sk_buff *skb, >> >> ph.raw = frame; >> >> + skb->ip_summed = CHECKSUM_UNNECESSARY; >> skb->protocol = proto; >> skb->dev = dev; >> skb->priority = po->sk.sk_priority; >> @@ -2805,6 +2807,7 @@ static struct sk_buff *packet_alloc_skb(struct >> sock *sk, size_t prepad, >> skb_put(skb, linear); >> skb->data_len = len - linear; >> skb->len += len - linear; >> + skb->ip_summed = CHECKSUM_UNNECESSARY; >> >> return skb; >> } > > > I have tested UDP, TCP, TCPv6 and custom Ethernet frames across a veth pair. > > And, UDP, TCP, and pktgen across a pair of veth pairs > bridged by my user-space packet filter. > > All of these tests work fine with your patch as far as I can tell. > > So, you can add: > > Tested-by: Ben Greear <gree...@candelatech.com> > > That said, it could easily break some drivers and/or other scenarios that I > have not tested, so at the least it should cook a while upstream before > going into the > stable tree.... > > > Thanks, > Ben > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com >