commit 1ea1c41db9839e56eb0f41dfffc7c6dd80bf7a64
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Aug 12 19:34:48 2017 -0700

    Linux 4.12.7

commit d5ad330817a3d6d3e781bd2d0edc72c72fed9e5c
Author: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date:   Thu Jun 22 10:01:21 2017 +0800

    btrfs: Remove false alert when fiemap range is smaller than on-disk extent
    
    commit 848c23b78fafdcd3270b06a30737f8dbd70c347f upstream.
    
    Commit 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent before
    submit it to user") introduced a warning to catch unemitted cached
    fiemap extent.
    
    However such warning doesn't take the following case into consideration:
    
    0                       4K                      8K
    |<---- fiemap range --->|
    |<----------- On-disk extent ------------------>|
    
    In this case, the whole 0~8K is cached, and since it's larger than
    fiemap range, it break the fiemap extent emit loop.
    This leaves the fiemap extent cached but not emitted, and caught by the
    final fiemap extent sanity check, causing kernel warning.
    
    This patch removes the kernel warning and renames the sanity check to
    emit_last_fiemap_cache() since it's possible and valid to have cached
    fiemap extent.
    
    Reported-by: David Sterba <dsterba@suse.cz>
    Reported-by: Adam Borowski <kilobyte@angband.pl>
    Fixes: 4751832da990 ("btrfs: fiemap: Cache and merge fiemap extent ...")
    Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Cc: Holger Hoffstätte <holger@applied-asynchrony.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4b3691a2c83c696ec65bdf9bda4b28095e18331
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Thu Jul 27 09:11:26 2017 +0200

    scsi: sg: only check for dxfer_len greater than 256M
    
    commit f930c7043663188429cd9b254e9d761edfc101ce upstream.
    
    Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the
    sg_io_hdr_t::dxferp in order to determine if it is a valid request. The
    only way we can check for bad requests is by checking if the length
    exceeds 256M.
    
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the
    request)
    Reported-by: Jason L Tibbitts III <tibbs@math.uh.edu>
    Tested-by: Jason L Tibbitts III <tibbs@math.uh.edu>
    Suggested-by: Doug Gilbert <dgilbert@interlog.com>
    Cc: Doug Gilbert <dgilbert@interlog.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91b2b39b49c25a0a76e3ef5302e848e6c9e60cfd
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu Aug 10 12:41:58 2017 -0400

    packet: fix tp_reserve race in packet_set_ring
    
    
    [ Upstream commit c27927e372f0785f3303e8fad94b85945e2c97b7 ]
    
    Updates to tp_reserve can race with reads of the field in
    packet_set_ring. Avoid this by holding the socket lock during
    updates in setsockopt PACKET_RESERVE.
    
    This bug was discovered by syzkaller.
    
    Fixes: 8913336a7e8d ("packet: add PACKET_RESERVE sockopt")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a8c396a689114da0fb9164cd07b13fd5b800782
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu Aug 10 12:29:19 2017 -0400

    udp: consistently apply ufo or fragmentation
    
    
    [ Upstream commit 85f1bd9a7b5a79d5baa8bf44af19658f7bf77bfa ]
    
    When iteratively building a UDP datagram with MSG_MORE and that
    datagram exceeds MTU, consistently choose UFO or fragmentation.
    
    Once skb_is_gso, always apply ufo. Conversely, once a datagram is
    split across multiple skbs, do not consider ufo.
    
    Sendpage already maintains the first invariant, only add the second.
    IPv6 does not have a sendpage implementation to modify.
    
    A gso skb must have a partial checksum, do not follow sk_no_check_tx
    in udp_send_skb.
    
    Found by syzkaller.
    
    Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b5e5a8d94853d6f6d461d6c6b7a87921adfcebd
Author: Nikolay Borisov <nborisov@suse.com>
Date:   Wed Aug 9 14:38:04 2017 +0300

    igmp: Fix regression caused by igmp sysctl namespace code.
    
    
    [ Upstream commit 1714020e42b17135032c8606f7185b3fb2ba5d78 ]
    
    Commit dcd87999d415 ("igmp: net: Move igmp namespace init to correct file")
    moved the igmp sysctls initialization from tcp_sk_init to igmp_net_init. This
    function is only called as part of per-namespace initialization, only if
    CONFIG_IP_MULTICAST is defined, otherwise igmp_mc_init() call in ip_init is
    compiled out, casuing the igmp pernet ops to not be registerd and those sysctl
    being left initialized with 0. However, there are certain functions, such as
    ip_mc_join_group which are always compiled and make use of some of those
    sysctls. Let's do a partial revert of the aforementioned commit and move the
    sysctl initialization into inet_init_net, that way they will always have
    sane values.
    
    Fixes: dcd87999d415 ("igmp: net: Move igmp namespace init to correct file")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196595
    Reported-by: Gerardo Exequiel Pozzi <vmlinuz386@gmail.com>
    Signed-off-by: Nikolay Borisov <nborisov@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8ad4bc97bd4223049ab8d48fa21d6ae1a5c7d448
Author: Willem de Bruijn <willemb@google.com>
Date:   Tue Aug 8 14:22:55 2017 -0400

    net: avoid skb_warn_bad_offload false positives on UFO
    
    
    [ Upstream commit 8d63bee643f1fb53e472f0e135cae4eb99d62d19 ]
    
    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@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c345783892eed49702acd9f7e2b48fbce6869c1
Author: Bjørn Mork <bjorn@mork.no>
Date:   Tue Aug 8 18:02:11 2017 +0200

    qmi_wwan: fix NULL deref on disconnect
    
    
    [ Upstream commit bbae08e592706dc32e5c7c97827b13c1c178668b ]
    
    qmi_wwan_disconnect is called twice when disconnecting devices with
    separate control and data interfaces.  The first invocation will set
    the interface data to NULL for both interfaces to flag that the
    disconnect has been handled.  But the matching NULL check was left
    out when qmi_wwan_disconnect was added, resulting in this oops:
    
      usb 2-1.4: USB disconnect, device number 4
      qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-0000:00:1d.0-1.4, WWAN/QMI device
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000e0
      IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
      PGD 0
      P4D 0
      Oops: 0000 [#1] SMP
      Modules linked in: <stripped irrelevant module list>
      CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: G            E   4.12.3-nr44-normandy-r1500619820+ #1
      Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 07/21/2017
      Workqueue: usb_hub_wq hub_event [usbcore]
      task: ffff8c882b716040 task.stack: ffffb8e800d84000
      RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
      RSP: 0018:ffffb8e800d87b38 EFLAGS: 00010246
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: ffff8c8824f3f1d0 RDI: ffff8c8824ef6400
      RBP: ffff8c8824ef6400 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffb8e800d87780 R11: 0000000000000011 R12: ffffffffc07ea0e8
      R13: ffff8c8824e2e000 R14: ffff8c8824e2e098 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff8c8835300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000e0 CR3: 0000000229ca5000 CR4: 00000000000406e0
      Call Trace:
       ? usb_unbind_interface+0x71/0x270 [usbcore]
       ? device_release_driver_internal+0x154/0x210
       ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
       ? usbnet_disconnect+0x6c/0xf0 [usbnet]
       ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
       ? usb_unbind_interface+0x71/0x270 [usbcore]
       ? device_release_driver_internal+0x154/0x210
    
    Reported-and-tested-by: Nathaniel Roach <nroach44@gmail.com>
    Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
    Cc: Daniele Palmas <dnlplm@gmail.com>
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70165c27891e1483dff31bed4b84d19907515655
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 8 01:41:58 2017 -0700

    tcp: fastopen: tcp_connect() must refresh the route
    
    
    [ Upstream commit 8ba60924710cde564a3905588b6219741d6356d0 ]
    
    With new TCP_FASTOPEN_CONNECT socket option, there is a possibility
    to call tcp_connect() while socket sk_dst_cache is either NULL
    or invalid.
    
     +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
     +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
     +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
     +0 connect(4, ..., ...) = 0
    
    << sk->sk_dst_cache becomes obsolete, or even set to NULL >>
    
     +1 sendto(4, ..., 1000, MSG_FASTOPEN, ..., ...) = 1000
    
    We need to refresh the route otherwise bad things can happen,
    especially when syzkaller is running on the host :/
    
    Fixes: 19f6d3f3c8422 ("net/tcp-fastopen: Add new API support")
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Acked-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5353157470b8f8dffac0a457bded8edf7374279f
Author: Xin Long <lucien.xin@gmail.com>
Date:   Wed Aug 9 18:15:19 2017 +0800

    net: sched: set xt_tgchk_param par.nft_compat as 0 in ipt_init_target
    
    
    [ Upstream commit 96d9703050a0036a3360ec98bb41e107c90664fe ]
    
    Commit 55917a21d0cc ("netfilter: x_tables: add context to know if
    extension runs from nft_compat") introduced a member nft_compat to
    xt_tgchk_param structure.
    
    But it didn't set it's value for ipt_init_target. With unexpected
    value in par.nft_compat, it may return unexpected result in some
    target's checkentry.
    
    This patch is to set all it's fields as 0 and only initialize the
    non-zero fields in ipt_init_target.
    
    v1->v2:
      As Wang Cong's suggestion, fix it by setting all it's fields as
      0 and only initializing the non-zero fields.
    
    Fixes: 55917a21d0cc ("netfilter: x_tables: add context to know if extension runs from nft_compat")
    Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 882cce21abed09efd6eb040f52d7e09dd01c2ad1
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Aug 8 15:25:25 2017 +0800

    net: sched: set xt_tgchk_param par.net properly in ipt_init_target
    
    
    [ Upstream commit ec0acb09313074ba1a4976945791d9c6815f39fb ]
    
    Now xt_tgchk_param par in ipt_init_target is a local varibale,
    par.net is not initialized there. Later when xt_check_target
    calls target's checkentry in which it may access par.net, it
    would cause kernel panic.
    
    Jaroslav found this panic when running:
    
      # ip link add TestIface type dummy
      # tc qd add dev TestIface ingress handle ffff:
      # tc filter add dev TestIface parent ffff: u32 match u32 0 0 \
        action xt -j CONNMARK --set-mark 4
    
    This patch is to pass net param into ipt_init_target and set
    par.net with it properly in there.
    
    v1->v2:
      As Wang Cong pointed, I missed ipt_net_id != xt_net_id, so fix
      it by also passing net_id to __tcf_ipt_init.
    v2->v3:
      Missed the fixes tag, so add it.
    
    Fixes: ecb2421b5ddf ("netfilter: add and use nf_ct_netns_get/put")
    Reported-by: Jaroslav Aster <jaster@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7be680f71d7d9338beaf00fd01806d751932c68a
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Thu Aug 3 22:54:48 2017 +0200

    net/mlx4_en: don't set CHECKSUM_COMPLETE on SCTP packets
    
    
    [ Upstream commit e718fe450e616227b74d27a233cdf37b4df0c82b ]
    
    if the NIC fails to validate the checksum on TCP/UDP, and validation of IP
    checksum is successful, the driver subtracts the pseudo-header checksum
    from the value obtained by the hardware and sets CHECKSUM_COMPLETE. Don't
    do that if protocol is IPPROTO_SCTP, otherwise CRC32c validation fails.
    
    V2: don't test MLX4_CQE_STATUS_IPV6 if MLX4_CQE_STATUS_IPV4 is set
    
    Reported-by: Shuang Li <shuali@redhat.com>
    Fixes: f8c6455bb04b ("net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE")
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Acked-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c531692a7f4d031584132a59dfaba055ace7f6a1
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Aug 4 14:20:54 2017 +0200

    bpf, s390: fix jit branch offset related to ldimm64
    
    
    [ Upstream commit b0a0c2566f28e71e5e32121992ac8060cec75510 ]
    
    While testing some other work that required JIT modifications, I
    run into test_bpf causing a hang when JIT enabled on s390. The
    problematic test case was the one from ddc665a4bb4b (bpf, arm64:
    fix jit branch offset related to ldimm64), and turns out that we
    do have a similar issue on s390 as well. In bpf_jit_prog() we
    update next instruction address after returning from bpf_jit_insn()
    with an insn_count. bpf_jit_insn() returns either -1 in case of
    error (e.g. unsupported insn), 1 or 2. The latter is only the
    case for ldimm64 due to spanning 2 insns, however, next address
    is only set to i + 1 not taking actual insn_count into account,
    thus fix is to use insn_count instead of 1. bpf_jit_enable in
    mode 2 provides also disasm on s390:
    
    Before fix:
    
      000003ff800349b6: a7f40003   brc     15,3ff800349bc                 ; target
      000003ff800349ba: 0000               unknown
      000003ff800349bc: e3b0f0700024       stg     %r11,112(%r15)
      000003ff800349c2: e3e0f0880024       stg     %r14,136(%r15)
      000003ff800349c8: 0db0               basr    %r11,%r0
      000003ff800349ca: c0ef00000000       llilf   %r14,0
      000003ff800349d0: e320b0360004       lg      %r2,54(%r11)
      000003ff800349d6: e330b03e0004       lg      %r3,62(%r11)
      000003ff800349dc: ec23ffeda065       clgrj   %r2,%r3,10,3ff800349b6 ; jmp
      000003ff800349e2: e3e0b0460004       lg      %r14,70(%r11)
      000003ff800349e8: e3e0b04e0004       lg      %r14,78(%r11)
      000003ff800349ee: b904002e   lgr     %r2,%r14
      000003ff800349f2: e3b0f0700004       lg      %r11,112(%r15)
      000003ff800349f8: e3e0f0880004       lg      %r14,136(%r15)
      000003ff800349fe: 07fe               bcr     15,%r14
    
    After fix:
    
      000003ff80ef3db4: a7f40003   brc     15,3ff80ef3dba
      000003ff80ef3db8: 0000               unknown
      000003ff80ef3dba: e3b0f0700024       stg     %r11,112(%r15)
      000003ff80ef3dc0: e3e0f0880024       stg     %r14,136(%r15)
      000003ff80ef3dc6: 0db0               basr    %r11,%r0
      000003ff80ef3dc8: c0ef00000000       llilf   %r14,0
      000003ff80ef3dce: e320b0360004       lg      %r2,54(%r11)
      000003ff80ef3dd4: e330b03e0004       lg      %r3,62(%r11)
      000003ff80ef3dda: ec230006a065       clgrj   %r2,%r3,10,3ff80ef3de6 ; jmp
      000003ff80ef3de0: e3e0b0460004       lg      %r14,70(%r11)
      000003ff80ef3de6: e3e0b04e0004       lg      %r14,78(%r11)          ; target
      000003ff80ef3dec: b904002e   lgr     %r2,%r14
      000003ff80ef3df0: e3b0f0700004       lg      %r11,112(%r15)
      000003ff80ef3df6: e3e0f0880004       lg      %r14,136(%r15)
      000003ff80ef3dfc: 07fe               bcr     15,%r14
    
    test_bpf.ko suite runs fine after the fix.
    
    Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f725c58799604308406e169b98e9e3955a97efae
Author: Xin Long <lucien.xin@gmail.com>
Date:   Thu Aug 3 14:13:46 2017 +0800

    ipv6: set rt6i_protocol properly in the route when it is installed
    
    
    [ Upstream commit b91d532928dff2141ea9c107c3e73104d9843767 ]
    
    After commit c2ed1880fd61 ("net: ipv6: check route protocol when
    deleting routes"), ipv6 route checks rt protocol when trying to
    remove a rt entry.
    
    It introduced a side effect causing 'ip -6 route flush cache' not
    to work well. When flushing caches with iproute, all route caches
    get dumped from kernel then removed one by one by sending DELROUTE
    requests to kernel for each cache.
    
    The thing is iproute sends the request with the cache whose proto
    is set with RTPROT_REDIRECT by rt6_fill_node() when kernel dumps
    it. But in kernel the rt_cache protocol is still 0, which causes
    the cache not to be matched and removed.
    
    So the real reason is rt6i_protocol in the route is not set when
    it is allocated. As David Ahern's suggestion, this patch is to
    set rt6i_protocol properly in the route when it is installed and
    remove the codes setting rtm_protocol according to rt6i_flags in
    rt6_fill_node.
    
    This is also an improvement to keep rt6i_protocol consistent with
    rtm_protocol.
    
    Fixes: c2ed1880fd61 ("net: ipv6: check route protocol when deleting routes")
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Suggested-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 963f8fb6b8e24944551a2777452edfc88064b481
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Aug 2 23:10:46 2017 -0700

    net: fix keepalive code vs TCP_FASTOPEN_CONNECT
    
    
    [ Upstream commit 2dda640040876cd8ae646408b69eea40c24f9ae9 ]
    
    syzkaller was able to trigger a divide by 0 in TCP stack [1]
    
    Issue here is that keepalive timer needs to be updated to not attempt
    to send a probe if the connection setup was deferred using
    TCP_FASTOPEN_CONNECT socket option added in linux-4.11
    
    [1]
     divide error: 0000 [#1] SMP
     CPU: 18 PID: 0 Comm: swapper/18 Not tainted
     task: ffff986f62f4b040 ti: ffff986f62fa2000 task.ti: ffff986f62fa2000
     RIP: 0010:[<ffffffff8409cc0d>]  [<ffffffff8409cc0d>] __tcp_select_window+0x8d/0x160
     Call Trace:
      <IRQ>
      [<ffffffff8409d951>] tcp_transmit_skb+0x11/0x20
      [<ffffffff8409da21>] tcp_xmit_probe_skb+0xc1/0xe0
      [<ffffffff840a0ee8>] tcp_write_wakeup+0x68/0x160
      [<ffffffff840a151b>] tcp_keepalive_timer+0x17b/0x230
      [<ffffffff83b3f799>] call_timer_fn+0x39/0xf0
      [<ffffffff83b40797>] run_timer_softirq+0x1d7/0x280
      [<ffffffff83a04ddb>] __do_softirq+0xcb/0x257
      [<ffffffff83ae03ac>] irq_exit+0x9c/0xb0
      [<ffffffff83a04c1a>] smp_apic_timer_interrupt+0x6a/0x80
      [<ffffffff83a03eaf>] apic_timer_interrupt+0x7f/0x90
      <EOI>
      [<ffffffff83fed2ea>] ? cpuidle_enter_state+0x13a/0x3b0
      [<ffffffff83fed2cd>] ? cpuidle_enter_state+0x11d/0x3b0
    
    Tested:
    
    Following packetdrill no longer crashes the kernel
    
    `echo 0 >/proc/sys/net/ipv4/tcp_timestamps`
    
    // Cache warmup: send a Fast Open cookie request
        0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
       +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
       +0 setsockopt(3, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
       +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation is now in progress)
       +0 > S 0:0(0) <mss 1460,nop,nop,sackOK,nop,wscale 8,FO,nop,nop>
     +.01 < S. 123:123(0) ack 1 win 14600 <mss 1460,nop,nop,sackOK,nop,wscale 6,FO abcd1234,nop,nop>
       +0 > . 1:1(0) ack 1
       +0 close(3) = 0
       +0 > F. 1:1(0) ack 1
       +0 < F. 1:1(0) ack 2 win 92
       +0 > .  2:2(0) ack 2
    
       +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4
       +0 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
       +0 setsockopt(4, SOL_TCP, TCP_FASTOPEN_CONNECT, [1], 4) = 0
       +0 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
     +.01 connect(4, ..., ...) = 0
       +0 setsockopt(4, SOL_TCP, TCP_KEEPIDLE, [5], 4) = 0
       +10 close(4) = 0
    
    `echo 1 >/proc/sys/net/ipv4/tcp_timestamps`
    
    Fixes: 19f6d3f3c842 ("net/tcp-fastopen: Add new API support")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fe3624211f7860b5d7b83fa04d71e85755a9244
Author: Yuchung Cheng <ycheng@google.com>
Date:   Tue Aug 1 13:22:32 2017 -0700

    tcp: avoid setting cwnd to invalid ssthresh after cwnd reduction states
    
    
    [ Upstream commit ed254971edea92c3ac5c67c6a05247a92aa6075e ]
    
    If the sender switches the congestion control during ECN-triggered
    cwnd-reduction state (CA_CWR), upon exiting recovery cwnd is set to
    the ssthresh value calculated by the previous congestion control. If
    the previous congestion control is BBR that always keep ssthresh
    to TCP_INIFINITE_SSTHRESH, cwnd ends up being infinite. The safe
    step is to avoid assigning invalid ssthresh value when recovery ends.
    
    Signed-off-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5028e6c9c5cea3b2be222f28ab1d11d932bc6e81
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Tue Aug 8 11:43:24 2017 +0200

    ppp: fix xmit recursion detection on ppp channels
    
    
    [ Upstream commit 0a0e1a85c83775a648041be2b15de6d0a2f2b8eb ]
    
    Commit e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp
    devices") dropped the xmit_recursion counter incrementation in
    ppp_channel_push() and relied on ppp_xmit_process() for this task.
    But __ppp_channel_push() can also send packets directly (using the
    .start_xmit() channel callback), in which case the xmit_recursion
    counter isn't incremented anymore. If such packets get routed back to
    the parent ppp unit, ppp_xmit_process() won't notice the recursion and
    will call ppp_channel_push() on the same channel, effectively creating
    the deadlock situation that the xmit_recursion mechanism was supposed
    to prevent.
    
    This patch re-introduces the xmit_recursion counter incrementation in
    ppp_channel_push(). Since the xmit_recursion variable is now part of
    the parent ppp unit, incrementation is skipped if the channel doesn't
    have any. This is fine because only packets routed through the parent
    unit may enter the channel recursively.
    
    Finally, we have to ensure that pch->ppp is not going to be modified
    while executing ppp_channel_push(). Instead of taking this lock only
    while calling ppp_xmit_process(), we now have to hold it for the full
    ppp_channel_push() execution. This respects the ppp locks ordering
    which requires locking ->upl before ->downl.
    
    Fixes: e5dadc65f9e0 ("ppp: Fix false xmit recursion detect with two ppp devices")
    Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 67410cd253ded750a5c88a5f67076c5d175a094a
Author: Gao Feng <gfree.wind@vip.163.com>
Date:   Mon Jul 17 18:34:42 2017 +0800

    ppp: Fix false xmit recursion detect with two ppp devices
    
    
    [ Upstream commit e5dadc65f9e0177eb649bcd9d333f1ebf871223e ]
    
    The global percpu variable ppp_xmit_recursion is used to detect the ppp
    xmit recursion to avoid the deadlock, which is caused by one CPU tries to
    lock the xmit lock twice. But it would report false recursion when one CPU
    wants to send the skb from two different PPP devices, like one L2TP on the
    PPPoE. It is a normal case actually.
    
    Now use one percpu member of struct ppp instead of the gloable variable to
    detect the xmit recursion of one ppp device.
    
    Fixes: 55454a565836 ("ppp: avoid dealock on recursive xmit")
    Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
    Signed-off-by: Liu Jianying <jianying.liu@ikuai8.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>