[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-L_S312Ryyg5fE3p6kqFus4SKQcgL2zXKiofq-ohiK7bg@mail.gmail.com>
Date: Mon, 11 Dec 2017 16:25:26 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Joseph Salisbury <joseph.salisbury@...onical.com>
Cc: Eric Dumazet <edumazet@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
David Miller <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
jakub.kicinski@...ronome.com, linux@...musvillemoes.dk,
John Fastabend <john.fastabend@...il.com>, me@...in.cc,
idosch@...lanox.com, Network Development <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, 1715609@...s.launchpad.net
Subject: Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce
skb_warn_bad_offload() noise
On Mon, Dec 11, 2017 at 3:35 PM, Joseph Salisbury
<joseph.salisbury@...onical.com> wrote:
> Hi Eric,
>
> A kernel bug report was opened against Ubuntu [0]. It was found that
> reverting the following commit resolved this bug:
The recorded trace in that bug is against 4.10.0 with some backports.
Given that commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload()
noise") is implicated, I guess that that was backported from 4.11-rc1.
The WARN shows
e1000e: caps=(0x00000030002149a9, 0x0000000000000000)
len=1701 data_len=1659 gso_size=1480 gso_type=2 ip_summed=0
The numbering changed in 4.14, but for this kernel
SKB_GSO_UDP = 1 << 1,
so this is a UFO packet with CHECKSUM_NONE. The stack shows
kernel: [570943.494549] skb_warn_bad_offload+0xd1/0x120
kernel: [570943.494550] __skb_gso_segment+0x17d/0x190
kernel: [570943.494564] validate_xmit_skb+0x14f/0x2a0
kernel: [570943.494565] validate_xmit_skb_list+0x43/0x70
so if that patch has been backported, then this must trigger in
__skb_gso_segment on the return path from skb_mac_gso_segment.
Did you backport
commit 8d63bee643f1fb53e472f0e135cae4eb99d62d19
Author: Willem de Bruijn <willemb@...gle.com>
Date: Tue Aug 8 14:22:55 2017 -0400
net: avoid skb_warn_bad_offload false positives on UFO
skb_warn_bad_offload triggers a warning when an skb enters the GSO
stack at __skb_gso_segment that does not have CHECKSUM_PARTIAL
checksum offload set.
Commit b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
observed that SKB_GSO_DODGY producers can trigger the check and
that passing those packets through the GSO handlers will fix it
up. But, the software UFO handler will set ip_summed to
CHECKSUM_NONE.
When __skb_gso_segment is called from the receive path, this
triggers the warning again.
Make UFO set CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE. On
Tx these two are equivalent. On Rx, this better matches the
skb state (checksum computed), as CHECKSUM_NONE here means no
checksum computed.
See also this thread for context:
http://patchwork.ozlabs.org/patch/799015/
Fixes: b2504a5dbef3 ("net: reduce skb_warn_bad_offload() noise")
Signed-off-by: Willem de Bruijn <willemb@...gle.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
Note that UFO was removed in 4.14 and that skb_warn_bad_offload
can happen for various types of packets, so there may be multiple
independent bug reports. I'm investigating two other non-UFO reports
just now.
Powered by blists - more mailing lists