On Fri, 2017-08-04 at 06:11 -0700, Tonghao Zhang wrote: > This patch will revert the b2504a5dbe "net: reduce > skb_warn_bad_offload() noise". The ovs will call the > __skb_gso_segment() with tx false. When segmenting UDP with UFO, > the __skb_gso_segment raises a warning as below [1], because the > ip_summed is CHECKSUM_NONE. While the net-next has removed the > UFO support, but the 4.11 and 4.12 kernel don't address that problem. > > In the kernel, only qdisc_pkt_len_init() (__dev_queue_xmit call it.) > uses the SKB_GSO_DODGY to do something. Other places just set it. > The warn described in b2504a5dbe is shown [2]. We may know that: > 1. the net_device don’t have qdisc. > 2. the skb->ip_summed was changed to CHECKSUM_NONE. it maybe > changed in skb_checksum_help() when calling validate_xmit_skb(). > or other place. > > And we should not revert the 6e7bc478c9 "net: skb_needs_check() accepts > CHECKSUM_NONE for tx". The check is necessary.
Why is it necessary ? If you revert b2504a5dbe, then we also need to revert 6e7bc478c9, unless you provide hard facts. > > [1] > [321428.168903] WARNING: CPU: 0 PID: 2279 at net/core/dev.c:2562 > skb_warn_bad_offload+0xc4/0x110 > [321428.168906] san0: caps=(0x000004009fbb58e9, 0x0000000000000000) len=6769 > data_len=6727 gso_size=1480 gso_type=2 ip_summed=0 > > [321428.168955] CPU: 0 PID: 2279 Comm: ruby-mri 4.11.12-200.fc25.x86_64 #1 > [321428.168956] Hardware name: Supermicro SYS-1028U-TNRTP+/X10DRU-i+, BIOS > 1.1 07/22/2015 > [321428.168957] Call Trace: > [321428.168962] dump_stack+0x63/0x86 > [321428.168965] __warn+0xcb/0xf0 > [321428.168966] warn_slowpath_fmt+0x5a/0x80 > [321428.168968] skb_warn_bad_offload+0xc4/0x110 > [321428.168970] __skb_gso_segment+0x190/0x1a0 > [321428.168977] queue_gso_packets+0x62/0x160 [openvswitch] > [321428.168992] ovs_dp_upcall+0x31/0x60 [openvswitch] > [321428.168994] ovs_dp_process_packet+0x10d/0x130 [openvswitch] > [321428.168997] ovs_vport_receive+0x76/0xd0 [openvswitch] > [321428.169013] internal_dev_xmit+0x28/0x60 [openvswitch] > [321428.169014] dev_hard_start_xmit+0xa3/0x1f0 > [321428.169016] __dev_queue_xmit+0x592/0x650 > [321428.169026] dev_queue_xmit+0x10/0x20 > > [2] > WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 > skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434 > lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 > gso_size=15883 gso_type=4 ip_summed=0 > Kernel panic - not syncing: panic_on_warn set ... > > CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e > ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1 > ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20 > Call Trace: Why are you adding this trace that was part of the b2504a5dbef3 changelog ? > [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline] > [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179 > [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542 > [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565 > [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434 > [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706 > [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline] > [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969 > [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383 > [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424 > > Cc: Eric Dumazet <eduma...@google.com> > Cc: Willem de Bruijn <will...@google.com> > Cc: Pravin B Shelar <pshe...@ovn.org> > Signed-off-by: Tonghao Zhang <xiangxia.m....@gmail.com> > --- IMO, this description is too confusing, I do not understand this patch.