netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	Mathieu Malaterre <malat@debian.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends"
Date: Wed, 20 Jun 2018 10:13:45 +1000	[thread overview]
Message-ID: <87muvqwc06.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <fbb95c11-240c-1a11-0a62-0483908c577e@gmail.com>

Eric Dumazet <eric.dumazet@gmail.com> writes:

> On 06/15/2018 11:56 AM, Mathieu Malaterre wrote:
>> This reverts commit 88078d98d1bb085d72af8437707279e203524fa5.
>> 
>> It causes regressions for people using chips driven by the sungem
>> driver. Suspicion is that the skb->csum value isn't being adjusted
>> properly.
>> 
>> Symptoms as seen on G4+sungem are:
>> 
>> [   34.023281] eth0: hw csum failure
>> [   34.023438] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #2
>> [   34.023618] Call Trace:
>> [   34.023707] [dffedbd0] [c069ddac] __skb_checksum_complete+0xf0/0x108 (unreliable)
>> [   34.023948] [dffedbf0] [c0777a70] tcp_v4_rcv+0x604/0xe00
>> [   34.024118] [dffedc70] [c0731624] ip_local_deliver_finish+0xa8/0x3c4
>> [   34.024315] [dffedcb0] [c0732430] ip_local_deliver+0xf0/0x154
>> [   34.024493] [dffedcf0] [c07328dc] ip_rcv+0x448/0x774
>> [   34.024653] [dffedd50] [c06aeae0] __netif_receive_skb_core+0x5e8/0x1184
>> [   34.024857] [dffedde0] [c06bba20] napi_gro_receive+0x160/0x22c
>> [   34.025044] [dffede10] [e14b2590] gem_poll+0x7fc/0x1ac0 [sungem]
>> [   34.025228] [dffedee0] [c06bacf0] net_rx_action+0x34c/0x618
>> [   34.025402] [dffedf60] [c07fd27c] __do_softirq+0x16c/0x5f0
>> [   34.025575] [dffedfd0] [c0064c7c] irq_exit+0x110/0x1a8
>> [   34.025738] [dffedff0] [c0016170] call_do_irq+0x24/0x3c
>> [   34.025903] [c0cf7e80] [c0009a84] do_IRQ+0x98/0x1a0
>> [   34.026055] [c0cf7eb0] [c001b474] ret_from_except+0x0/0x14
>> [   34.026225] --- interrupt: 501 at arch_cpu_idle+0x30/0x78
>>                    LR = arch_cpu_idle+0x30/0x78
>> [   34.026510] [c0cf7f70] [c0cf6000] 0xc0cf6000 (unreliable)
>> [   34.026682] [c0cf7f80] [c00a3868] do_idle+0xc4/0x158
>> [   34.026835] [c0cf7fb0] [c00a3ab0] cpu_startup_entry+0x20/0x28
>> [   34.027013] [c0cf7fc0] [c0998820] start_kernel+0x47c/0x490
>> [   34.027181] [c0cf7ff0] [00003444] 0x3444
>> 
>> See commit 7ce5a27f2ef8 ("Revert "net: Handle CHECKSUM_COMPLETE more
>> adequately in pskb_trim_rcsum()."") for previous reference.
>
> This fix seems to hide a bug in csum functions on this architecture.
>
> Or a bug on this NIC when receiving a small packet (less than 60 bytes).
> Maybe the padding bytes are not included in NIC provided csum, and not 0.

Just so I'm clear, this turned out to be a driver/hw problem rather than
the arch csum implementation?

cheers

  parent reply	other threads:[~2018-06-20  0:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 18:56 [PATCH] Revert "net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends" Mathieu Malaterre
2018-06-15 19:14 ` Eric Dumazet
2018-06-16  7:14   ` Mathieu Malaterre
2018-06-16 12:45     ` Eric Dumazet
2018-06-17 10:27       ` Andreas Schwab
2018-06-17 22:54         ` Eric Dumazet
2018-06-18 17:54           ` Andreas Schwab
2018-06-18 18:18             ` Eric Dumazet
2018-06-18 18:45               ` Mathieu Malaterre
2018-06-18 23:29                 ` Eric Dumazet
2018-06-18 23:36                   ` Eric Dumazet
2018-06-19 19:10                     ` Andreas Schwab
2018-06-19 20:10                       ` Eric Dumazet
2018-06-19 22:10                         ` Eric Dumazet
2018-06-19 22:32                           ` Andreas Schwab
2018-06-19 22:40                             ` Eric Dumazet
2018-06-18 18:29             ` Mathieu Malaterre
2018-06-17 10:09     ` Andreas Schwab
2018-06-20  0:13   ` Michael Ellerman [this message]
2018-06-20  0:19     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muvqwc06.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malat@debian.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).