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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTSc0Acy4J8yTraD+_yS4juWVBFjOk4cgqaB7jzOuq_9sig@mail.gmail.com>
Date:   Sun, 22 Mar 2020 10:40:00 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Yadu Kishore <kyk.segfault@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        David Laight <David.Laight@...lab.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH v3] net: Make skb_segment not to compute checksum if
 network controller supports checksumming

On Tue, Mar 17, 2020 at 4:39 AM Yadu Kishore <kyk.segfault@...il.com> wrote:
>
>
> > I think you can rebase and submit against net-next.
>
> > If your patch isn't active in the networking development patchwork instance,
> > it is not pending to be applied and you must resend it.
>
> Rebasing the patch on net-next and resending it.
>
> Problem:
> TCP checksum in the output path is not being offloaded during GSO
> in the following case:
> The network driver does not support scatter-gather but supports
> checksum offload with NETIF_F_HW_CSUM.
>
> Cause:
> skb_segment calls skb_copy_and_csum_bits if the network driver
> does not announce NETIF_F_SG. It does not check if the driver
> supports NETIF_F_HW_CSUM.
> So for devices which might want to offload checksum but do not support SG
> there is currently no way to do so if GSO is enabled.
>
> Solution:
> In skb_segment check if the network controller does checksum and if so
> call skb_copy_bits instead of skb_copy_and_csum_bits.
>
> Testing:
> Without the patch, ran iperf TCP traffic with NETIF_F_HW_CSUM enabled
> in the network driver. Observed the TCP checksum offload is not happening
> since the skbs received by the driver in the output path have
> skb->ip_summed set to CHECKSUM_NONE.
>
> With the patch ran iperf TCP traffic and observed that TCP checksum
> is being offloaded with skb->ip_summed set to CHECKSUM_PARTIAL.
> Also tested with the patch by disabling NETIF_F_HW_CSUM in the driver
> to cover the newly introduced if-else code path in skb_segment.
>
> Link: https://lore.kernel.org/netdev/CA+FuTSeYGYr3Umij+Mezk9CUcaxYwqEe5sPSuXF8jPE2yMFJAw@mail.gmail.com
> Signed-off-by: Yadu Kishore <kyk.segfault@...il.com>

Acked-by: Willem de Bruijn <willemb@...gle.com>

Given that there are multiple micro architectures on which this is
apparently a win, it makes sense (even if we should also optimize
those arch specific csum codes).

The tricky part here is not the basic operation, but how this behaves
with the skb_gso_cb infra for handling multiple checksums, some of
which may be computed in software, such as with remote checksum
offload.

In the case of CHECKSUM_PARTIAL the csum is not computed. Inner
most segmentation protocols (tcp/udp) will call gso_reset_checksum on
return from skb_segment to set up these skb_gso_cb fields. So this
looks correct to me.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ