From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: Latest net-next kernel 4.19.0+
Date: Tue, 30 Oct 2018 00:29:13 -0700
Message-ID: <68f25a28-b79e-d3ae-6eef-50c354ad63ae@gmail.com>
References: <59d5657c-ea0a-7b64-d5ff-5b55eb4fcccf@itcare.pl>
 <ec5c3923-a268-aa2c-fea1-350f8bce65c2@itcare.pl>
 <CAM_iQpWWZqur_dLC_eM7iX7BFDncrYFSXHohwxCt2xMaAjRpMQ@mail.gmail.com>
 <1e954663-ed05-4f33-4384-db880844f9d1@gmail.com>
 <db6848dc-cf1b-0989-570c-af5bdd1a7bd1@gmail.com>
 <CAG76SjY7fnFdgamBELATyO8NGnyNFYiX33SgLE6-q=eoBM8jKg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
        =?UTF-8?Q?Pawe=c5=82_Staszewski?= <pstaszewski@itcare.pl>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>
To: Dimitris Michailidis <dmichail@google.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf1-f180.google.com ([209.85.210.180]:33912 "EHLO
        mail-pf1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726336AbeJ3QVe (ORCPT
        <rfc822;netdev@vger.kernel.org>); Tue, 30 Oct 2018 12:21:34 -0400
Received: by mail-pf1-f180.google.com with SMTP id f78-v6so5372126pfe.1
        for <netdev@vger.kernel.org>; Tue, 30 Oct 2018 00:29:15 -0700 (PDT)
In-Reply-To: <CAG76SjY7fnFdgamBELATyO8NGnyNFYiX33SgLE6-q=eoBM8jKg@mail.gmail.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>



On 10/29/2018 11:09 PM, Dimitris Michailidis wrote:

> 
> Indeed this is a bug. I would expect it to produce frequent errors
> though as many odd-length
> packets would trigger it. Do you have RXFCS? Regardless, how
> frequently do you see the problem?
> 

Old kernels (before 88078d98d1bb) were simply resetting ip_summed to CHECKSUM_NONE

And before your fix (commit d55bef5059dd057bd), mlx5 bug was canceling the bug you fixed.

So we now need to also fix mlx5.

And of course use skb_header_pointer() in mlx5e_get_fcs() as I mentioned earlier,
plus __get_unaligned_cpu32() as you hinted.