[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S36cqecPH+Zd8pGVdFHRi7bmWgAwm2UgFVprt5JOuO47UA@mail.gmail.com>
Date: Sat, 30 Apr 2016 12:54:37 -0700
From: Tom Herbert <tom@...bertland.com>
To: Ben Greear <greearb@...delatech.com>
Cc: Ben Hutchings <ben@...adent.org.uk>,
Sabrina Dubroca <sd@...asysnail.net>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
akpm@...ux-foundation.org, "David S. Miller" <davem@...emloft.net>,
Vijay Pandurangan <vijayp@...ayp.ca>,
Cong Wang <cwang@...pensource.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Evan Jones <ej@...njones.ca>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Phil Sutter <phil@....cc>,
Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.
We've put considerable effort into cleaning up the checksum interface
to make it as unambiguous as possible, please be very careful to
follow it. Broken checksum processing is really hard to detect and
debug.
CHECKSUM_UNNECESSARY means that some number of _specific_ checksums
(indicated by csum_level) have been verified to be correct in a
packet. Blindly promoting CHECKSUM_NONE to CHECKSUM_UNNECESSARY is
never right. If CHECKSUM_UNNECESSARY is set in such a manner but the
checksum it would refer to has not been verified and is incorrect this
is a major bug.
Tom
On Sat, Apr 30, 2016 at 12:40 PM, Ben Greear <greearb@...delatech.com> wrote:
>
>
> On 04/30/2016 11:33 AM, Ben Hutchings wrote:
>>
>> On Thu, 2016-04-28 at 12:29 +0200, Sabrina Dubroca wrote:
>>>
>>> Hello,
>
>
>>>>
>>>> http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=commitdiff;h=8153e983c0e5eba1aafe1fc296248ed2a553f1ac;hp=454b07405d694dad52e7f41af5816eed0190da8a
>>>
>>> Actually, no, this is not really a regression.
>>
>> [...]
>>
>> It really is. Even though the old behaviour was a bug (raw packets
>> should not be changed), if there are real applications that depend on
>> that then we have to keep those applications working somehow.
>
>
> To be honest, I fail to see why the old behaviour is a bug when sending
> raw packets from user-space. If raw packets should not be changed, then
> we need some way to specify what the checksum setting is to begin with,
> otherwise, user-space has not enough control.
>
> A socket option for new programs, and sysctl configurable defaults for raw
> sockets
> for old binary programs would be sufficient I think.
>
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@...delatech.com>
> Candela Technologies Inc http://www.candelatech.com
Powered by blists - more mailing lists