netdev - Re: [PATCH net 1/1] openvswitch: Fix setting ipv6 fields causing hw csum failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <efc0576f-431e-d1c1-be1-14c28fc064e5@nvidia.com>
Date:   Sun, 13 Feb 2022 09:58:04 +0200
From:   Paul Blakey <paulb@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <dev@...nvswitch.org>, <netdev@...r.kernel.org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Pravin B Shelar <pshelar@....org>, <davem@...emloft.net>,
        Eelco Chaudron <echaudro@...hat.com>,
        Oz Shlomo <ozsh@...dia.com>, "Vlad Buslov" <vladbu@...dia.com>,
        Roi Dayan <roid@...dia.com>,
        Ariel Levkovich <lariel@...dia.com>
Subject: Re: [PATCH net 1/1] openvswitch: Fix setting ipv6 fields causing hw
 csum failure



On Thu, 10 Feb 2022, Jakub Kicinski wrote:

> On Thu, 10 Feb 2022 10:53:24 +0200 Paul Blakey wrote:
> > > The calls seem a little heavy for single byte replacements.
> > > Can you instead add a helper based on csum_replace4() maybe?
> > > 
> > > BTW doesn't pedit have the same problem?
> > 
> > I don't think they are heavier then csum_replace4,
> 
> csum_replace4 is a handful of instructions all of which will be inlined.
> csum_partial() is a function call and handles variable lengths.
> 
> > but they are more bulletproof in my opinion, since they handle both
> > the COMPLETE and PARTIAL csum cases (in __skb_postpull_rcsum())
> 
> Yes, that's why I said "add a helper based on", a skb helper which
> checks the csum type of the packet but instead of calling csum_partial
> for no reason does the adjustment directly.

Then sure, I will do that and send v2.

> 
> > and resemble what editing of the packet should have done - pull the
> > header, edit, and then push it back.
> 
> That's not what this code is doing, so the argument does not stand IMO.
>