[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpUgCf86eZ1+-3peJ4ij39QCQeQwGRAaoDeiL3HxCCMRKQ@mail.gmail.com>
Date: Fri, 25 Mar 2016 15:16:55 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Ben Greear <greearb@...delatech.com>
Cc: Vijay Pandurangan <vijayp@...ayp.ca>,
netdev <netdev@...r.kernel.org>, Evan Jones <ej@...njones.ca>,
Cong Wang <cwang@...pensource.com>
Subject: Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good."
On Fri, Mar 25, 2016 at 1:56 PM, Ben Greear <greearb@...delatech.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 <greearb@...delatech.com>
Thanks for testing! I will send it out formally after I audit more drivers,
also let's give Tom some time to response.
>
> 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....
Yeah.
Thanks.
Powered by blists - more mailing lists