From: Greg KH <greg@kroah.com>
To: Vinson Lee <vlee@freedesktop.org>
Cc: stable@vger.kernel.org, Neal Cardwell <ncardwell@google.com>,
Yuchung Cheng <ycheng@google.com>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [stable request 4.4] tcp: fix tcp_mark_head_lost to check skb len before fragmenting
Date: Tue, 27 Jun 2017 13:31:49 +0200 [thread overview]
Message-ID: <20170627113149.GI10609@kroah.com> (raw)
In-Reply-To: <CACKvgLFjPo-aS6=k_QakgYOUjHgmU5LSegb0D68_n2OT9tuFEg@mail.gmail.com>
On Mon, Jun 19, 2017 at 02:51:20PM -0700, Vinson Lee wrote:
> Hi.
>
> I am seeing this warning on this 4.4.62 based kernel from Ubuntu 16.04.
>
> ------------[ cut here ]------------
> WARNING: CPU: 13 PID: 0 at
> /build/linux-0XAgc4/linux-4.4.0/net/ipv4/tcp_output.c:1145
> tcp_fragment+0x34d/0x370()
> Modules linked in: ip6table_filter ipip tunnel4 ip_tunnel cpuid 8021q
> garp mrp stp llc ip6_tables binfmt_misc xt_comment nf_log_ipv4
> nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype iptable_filter
> iptable_mangle iptable_raw ip_tables x_tables intel_rapl
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
> ipmi_ssif aes_x86_64 lrw gf128mul glue_helper ablk_helper hpilo cryptd
> serio_raw sb_edac edac_core ioatdma lpc_ich shpchp 8250_fintek mac_hid
> acpi_power_meter ipmi_si ipmi_devintf ipmi_msghandler autofs4 raid10
> raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor
> raid6_pq libcrc32c raid1 raid0 multipath linear ixgbe dca vxlan
> ip6_udp_tunnel udp_tunnel ptp ahci pps_core psmouse libahci
> mdio wmi fjes [last unloaded: nf_conntrack]
> CPU: 13 PID: 0 Comm: swapper/13 Not tainted 4.4.0-78-generic #99-Ubuntu
> 0000000000000286 24b314fc942cf971 ffff88105f3439a8 ffffffff813f8dd3
> 0000000000000000 ffffffff81d71d78 ffff88105f3439e0 ffffffff81081302
> ffff88088a1c5000 ffff880cc988f800 000000000000004b 0000000000000000
> Call Trace:
> <IRQ> [<ffffffff813f8dd3>] dump_stack+0x63/0x90
> [<ffffffff81081302>] warn_slowpath_common+0x82/0xc0
> [<ffffffff8108144a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff817903ad>] tcp_fragment+0x34d/0x370
> [<ffffffff81785b7f>] tcp_mark_head_lost+0x14f/0x240
> [<ffffffff8178692c>] tcp_update_scoreboard+0x4c/0x70
> [<ffffffff8178c3d2>] tcp_fastretrans_alert+0x6f2/0xaa0
> [<ffffffff8178cbeb>] tcp_ack+0x46b/0x800
> [<ffffffff8178da39>] tcp_rcv_established+0x1d9/0x780
> [<ffffffff8174c232>] ? sk_filter_trim_cap+0x42/0x160
> [<ffffffff81798a05>] tcp_v4_do_rcv+0x145/0x200
> [<ffffffff81799bf2>] tcp_v4_rcv+0x872/0xa20
> [<ffffffffc02290c7>] ? iptable_filter_hook+0x27/0x56 [iptable_filter]
> [<ffffffff8176c172>] ? nf_iterate+0x62/0x80
> [<ffffffff81773504>] ip_local_deliver_finish+0x94/0x1e0
> [<ffffffff8177380f>] ip_local_deliver+0x6f/0xe0
> [<ffffffff81773470>] ? ip_rcv_finish+0x320/0x320
> [<ffffffff817731e2>] ip_rcv_finish+0x92/0x320
> [<ffffffff81773b11>] ip_rcv+0x291/0x3a0
> [<ffffffff81773150>] ? inet_del_offload+0x40/0x40
> [<ffffffff817357a4>] __netif_receive_skb_core+0x704/0xa60
> [<ffffffff8179ec00>] ? tcp4_gro_receive+0x130/0x1d0
> [<ffffffff81735b18>] __netif_receive_skb+0x18/0x60
> [<ffffffff81735b92>] netif_receive_skb_internal+0x32/0xa0
> [<ffffffff81736813>] napi_gro_receive+0xc3/0x120
> [<ffffffffc02b8dfa>] gro_cell_poll+0x5a/0x90 [ip_tunnel]
> [<ffffffff8173605e>] net_rx_action+0x21e/0x360
> [<ffffffff81085de1>] __do_softirq+0x101/0x290
> [<ffffffff810860e3>] irq_exit+0xa3/0xb0
> [<ffffffff81050e13>] smp_call_function_single_interrupt+0x33/0x40
> [<ffffffff81841e62>] call_function_single_interrupt+0x82/0x90
> <EOI> [<ffffffff816d4131>] ? cpuidle_enter_state+0x111/0x2b0
> [<ffffffff816d4307>] cpuidle_enter+0x17/0x20
> [<ffffffff810c4592>] call_cpuidle+0x32/0x60
> [<ffffffff816d42e3>] ? cpuidle_select+0x13/0x20
> [<ffffffff810c4850>] cpu_startup_entry+0x290/0x350
> [<ffffffff810517c4>] start_secondary+0x154/0x190
> ---[ end trace f0d076c2d7e8bb40 ]---
>
>
> This might be fixed by upstream Linux 4.5 commit "tcp: fix
> tcp_mark_head_lost to check skb len before fragmenting". If so, would
> you please consider backporting this patch to stable series Linux 4.4?
Have you tested this to see if it does resolve the issue or not? That
would be helpful :)
thanks,
greg k-h
next prev parent reply other threads:[~2017-06-27 11:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 21:51 [stable request 4.4] tcp: fix tcp_mark_head_lost to check skb len before fragmenting Vinson Lee
2017-06-27 11:31 ` Greg KH [this message]
2017-07-06 17:23 ` Vinson Lee
[not found] ` <CADVnQy=o3Hwo--2p5KbcJubwHkHp0JShFHqrc=2E8guDDzk6oQ@mail.gmail.com>
2017-07-13 14:01 ` Greg KH
2017-07-13 14:06 ` Neal Cardwell
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=20170627113149.GI10609@kroah.com \
--to=greg@kroah.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ncardwell@google.com \
--cc=stable@vger.kernel.org \
--cc=vlee@freedesktop.org \
--cc=ycheng@google.com \
/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