commit 9a2e216d9e892249b63d10603c75495749202df9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Mar 31 18:10:43 2018 +0200

    Linux 4.14.32

commit bba757a2c128ff890025acd1122e844faeb809ec
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Tue Mar 20 07:59:15 2018 +0100

    s390/qeth: on channel error, reject further cmd requests
    
    
    [ Upstream commit a6c3d93963e4b333c764fde69802c3ea9eaa9d5c ]
    
    When the IRQ handler determines that one of the cmd IO channels has
    failed and schedules recovery, block any further cmd requests from
    being submitted. The request would inevitably stall, and prevent the
    recovery from making progress until the request times out.
    
    This sort of error was observed after Live Guest Relocation, where
    the pending IO on the READ channel intentionally gets terminated to
    kick-start recovery. Simultaneously the guest executed SIOCETHTOOL,
    triggering qeth to issue a QUERY CARD INFO command. The command
    then stalled in the inoperabel WRITE channel.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5245642201733746170c0f8abc6b7cfaac7e531
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Tue Mar 20 07:59:14 2018 +0100

    s390/qeth: lock read device while queueing next buffer
    
    
    [ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ]
    
    For calling ccw_device_start(), issue_next_read() needs to hold the
    device's ccwlock.
    This is satisfied for the IRQ handler path (where qeth_irq() gets called
    under the ccwlock), but we need explicit locking for the initial call by
    the MPC initialization.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd5ec7314030ed1e536244e8be1cbed8188616ac
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Tue Mar 20 07:59:13 2018 +0100

    s390/qeth: when thread completes, wake up all waiters
    
    
    [ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ]
    
    qeth_wait_for_threads() is potentially called by multiple users, make
    sure to notify all of them after qeth_clear_thread_running_bit()
    adjusted the thread_running_mask. With no timeout, callers would
    otherwise stall.
    
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b469bdd0f511f510bd99a4a62796cfe1310a2e09
Author: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date:   Tue Mar 20 07:59:12 2018 +0100

    s390/qeth: free netdevice when removing a card
    
    
    [ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ]
    
    On removal, a qeth card's netdevice is currently not properly freed
    because the call chain looks as follows:
    
    qeth_core_remove_device(card)
            lx_remove_device(card)
                    unregister_netdev(card->dev)
                    card->dev = NULL                        !!!
            qeth_core_free_card(card)
                    if (card->dev)                          !!!
                            free_netdev(card->dev)
    
    Fix it by free'ing the netdev straight after unregistering. This also
    fixes the sysfs-driven layer switch case (qeth_dev_layer2_store()),
    where the need to free the current netdevice was not considered at all.
    
    Note that free_netdev() takes care of the netif_napi_del() for us too.
    
    Fixes: 4a71df50047f ("qeth: new qeth device driver")
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Reviewed-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 299902b581ea6c9d3c05ac1f06851969b68626c6
Author: Camelia Groza <camelia.groza@nxp.com>
Date:   Wed Mar 14 08:37:32 2018 -0500

    dpaa_eth: remove duplicate increment of the tx_errors counter
    
    
    [ Upstream commit 82d141cd19d088ee41feafde4a6f86eeb40d93c5 ]
    
    The tx_errors counter is incremented by the dpaa_xmit caller.
    
    Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bf75fca436785a3b7a175ec56eb74f6e3bf3b4b
Author: Camelia Groza <camelia.groza@nxp.com>
Date:   Wed Mar 14 08:37:31 2018 -0500

    dpaa_eth: increment the RX dropped counter when needed
    
    
    [ Upstream commit e4d1b37c17d000a3da9368a3e260fb9ea4927c25 ]
    
    Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dde9b6a837975a39051d99127f952314dc39e016
Author: Camelia Groza <camelia.groza@nxp.com>
Date:   Wed Mar 14 08:37:30 2018 -0500

    dpaa_eth: remove duplicate initialization
    
    
    [ Upstream commit 565186362b73226a288830abe595f05f0cec0bbc ]
    
    The fd_format has already been initialized at this point.
    
    Signed-off-by: Camelia Groza <camelia.groza@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bbb99d2fde047df596379be6c58e265e2ddbe1f
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date:   Wed Mar 14 08:37:29 2018 -0500

    dpaa_eth: fix error in dpaa_remove()
    
    
    [ Upstream commit 88075256ee817041d68c2387f29065b5cb2b342a ]
    
    The recent changes that make the driver probing compatible with DSA
    were not propagated in the dpa_remove() function, breaking the
    module unload function. Using the proper device to address the issue.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29cd9c2d1f428c281962135ea046a9d7bda88d14
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date:   Wed Mar 14 08:37:28 2018 -0500

    soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
    
    
    [ Upstream commit 96f413f47677366e0ae03797409bfcc4151dbf9e ]
    
    The wait_for_completion() call in qman_delete_cgr_safe()
    was triggering a scheduling while atomic bug, replacing the
    kthread with a smp_call_function_single() call to fix it.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
    Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43d8f3c5d3ad77329545f5464c2b7e08074eea1a
Author: Arkadi Sharshevsky <arkadis@mellanox.com>
Date:   Thu Mar 8 12:42:10 2018 +0200

    team: Fix double free in error path
    
    
    [ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ]
    
    The __send_and_alloc_skb() receives a skb ptr as a parameter but in
    case it fails the skb is not valid:
    - Send failed and released the skb internally.
    - Allocation failed.
    
    The current code tries to release the skb in case of failure which
    causes redundant freeing.
    
    Fixes: 9b00cf2d1024 ("team: implement multipart netlink messages for options transfers")
    Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.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 329f4710f89c028d5a8904040af913dfc5727362
Author: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Date:   Wed Mar 14 13:32:09 2018 -0700

    skbuff: Fix not waking applications when errors are enqueued
    
    
    [ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ]
    
    When errors are enqueued to the error queue via sock_queue_err_skb()
    function, it is possible that the waiting application is not notified.
    
    Calling 'sk->sk_data_ready()' would not notify applications that
    selected only POLLERR events in poll() (for example).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Randy E. Witt <randy.e.witt@intel.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e90e9771d9a33b8b14486c69c1b3183978d23eb5
Author: Michal Kalderon <Michal.Kalderon@cavium.com>
Date:   Wed Mar 14 14:56:53 2018 +0200

    qede: Fix qedr link update
    
    
    [ Upstream commit 4609adc27175839408359822523de7247d56c87f ]
    
    Link updates were not reported to qedr correctly.
    Leading to cases where a link could be down, but qedr
    would see it as up.
    In addition, once qede was loaded, link state would be up,
    regardless of the actual link state.
    
    Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
    Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6841b478e6bb9493fbaccaf50f4c8a2f66f3219
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Tue Mar 13 14:45:07 2018 -0700

    net: systemport: Rewrite __bcm_sysport_tx_reclaim()
    
    
    [ Upstream commit 484d802d0f2f29c335563fcac2a8facf174a1bbc ]
    
    There is no need for complex checking between the last consumed index
    and current consumed index, a simple subtraction will do.
    
    This also eliminates the possibility of a permanent transmit queue stall
    under the following conditions:
    
    - one CPU bursts ring->size worth of traffic (up to 256 buffers), to the
      point where we run out of free descriptors, so we stop the transmit
      queue at the end of bcm_sysport_xmit()
    
    - because of our locking, we have the transmit process disable
      interrupts which means we can be blocking the TX reclamation process
    
    - when TX reclamation finally runs, we will be computing the difference
      between ring->c_index (last consumed index by SW) and what the HW
      reports through its register
    
    - this register is masked with (ring->size - 1) = 0xff, which will lead
      to stripping the upper bits of the index (register is 16-bits wide)
    
    - we will be computing last_tx_cn as 0, which means there is no work to
      be done, and we never wake-up the transmit queue, leaving it
      permanently disabled
    
    A practical example is e.g: ring->c_index aka last_c_index = 12, we
    pushed 256 entries, HW consumer index = 268, we mask it with 0xff = 12,
    so last_tx_cn == 0, nothing happens.
    
    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 474aa5149753393c97ac01780cfb234194d5b91c
Author: David Ahern <dsahern@gmail.com>
Date:   Fri Feb 16 11:03:03 2018 -0800

    net: Only honor ifindex in IP_PKTINFO if non-0
    
    
    [ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ]
    
    Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings
    if the index is actually set in the message.
    
    Signed-off-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06d3f43d52bbf58dd040c7612ac7372cf6649208
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Wed Mar 14 21:10:23 2018 +0100

    netlink: avoid a double skb free in genlmsg_mcast()
    
    
    [ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ]
    
    nlmsg_multicast() consumes always the skb, thus the original skb must be
    freed only when this function is called with a clone.
    
    Fixes: cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2980f37b6111557c2d8dbb08bce2e14bdbb83fb2
Author: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date:   Tue Mar 13 16:50:06 2018 +0100

    net/iucv: Free memory obtained by kzalloc
    
    
    [ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ]
    
    Free memory by calling put_device(), if afiucv_iucv_init is not
    successful.
    
    Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com>
    Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a14b791d9863539b63b38bfab133b28fdd5029d4
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Sun Mar 18 12:49:51 2018 -0700

    net: fec: Fix unbalanced PM runtime calls
    
    
    [ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ]
    
    When unbinding/removing the driver, we will run into the following warnings:
    
    [  259.655198] fec 400d1000.ethernet: 400d1000.ethernet supply phy not found, using dummy regulator
    [  259.665065] fec 400d1000.ethernet: Unbalanced pm_runtime_enable!
    [  259.672770] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
    [  259.683062] fec 400d1000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: f2:3e:93:b7:29:c1
    [  259.696239] libphy: fec_enet_mii_bus: probed
    
    Avoid these warnings by balancing the runtime PM calls during fec_drv_remove().
    
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9cdb0f25fbb4b46ed46361a962f98cfffc4640a9
Author: SZ Lin (林上智) <sz.lin@moxa.com>
Date:   Fri Mar 16 00:56:01 2018 +0800

    net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface
    
    
    [ Upstream commit f9db50691db4a7d860fce985f080bb3fc23a7ede ]
    
    According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
    DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
    available when PHY is configured in RGMII mode with 10Mbps speed. It will
    cause some networking issues without RGMII mode, such as carrier sense
    errors and low throughput. TI also mentioned this issue in their forum[4].
    
    This patch adds the check mechanism for PHY interface with RGMII interface
    type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
    
    References:
    [1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
    [2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
    [3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
    [4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
    
    Suggested-by: Holsety Chen (陳憲輝) <Holsety.Chen@moxa.com>
    Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
    Signed-off-by: Schuyler Patton <spatton@ti.com>
    Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89142a0e0b70ffa5d47175dd881aaba21e5875cb
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Mar 18 23:59:36 2018 +0100

    net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred
    
    
    [ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ]
    
    If the optional regulator is deferred, we must release some resources.
    They will be re-allocated when the probe function will be called again.
    
    Fixes: 6eacf31139bf ("ethernet: arc: Add support for Rockchip SoC layer device tree bindings")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d5b0ed04c5ab5e0bd7626b27161ea055e578963
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Mar 6 07:54:53 2018 -0800

    l2tp: do not accept arbitrary sockets
    
    
    [ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ]
    
    syzkaller found an issue caused by lack of sufficient checks
    in l2tp_tunnel_create()
    
    RAW sockets can not be considered as UDP ones for instance.
    
    In another patch, we shall replace all pr_err() by less intrusive
    pr_debug() so that syzkaller can find other bugs faster.
    Acked-by: Guillaume Nault <g.nault@alphalink.fr>
    Acked-by: James Chapman <jchapman@katalix.com>
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
    dst_release: dst:00000000d53d0d0f refcnt:-1
    Write of size 1 at addr ffff8801d013b798 by task syz-executor3/6242
    
    CPU: 1 PID: 6242 Comm: syz-executor3 Not tainted 4.16.0-rc2+ #253
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:17 [inline]
     dump_stack+0x194/0x24d lib/dump_stack.c:53
     print_address_description+0x73/0x250 mm/kasan/report.c:256
     kasan_report_error mm/kasan/report.c:354 [inline]
     kasan_report+0x23b/0x360 mm/kasan/report.c:412
     __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
     setup_udp_tunnel_sock+0x3ee/0x5f0 net/ipv4/udp_tunnel.c:69
     l2tp_tunnel_create+0x1354/0x17f0 net/l2tp/l2tp_core.c:1596
     pppol2tp_connect+0x14b1/0x1dd0 net/l2tp/l2tp_ppp.c:707
     SYSC_connect+0x213/0x4a0 net/socket.c:1640
     SyS_connect+0x24/0x30 net/socket.c:1621
     do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18c647456ac9d61371a69e447df74daf9730f987
Author: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Date:   Thu Mar 8 17:00:02 2018 +0100

    ipv6: fix access to non-linear packet in ndisc_fill_redirect_hdr_option()
    
    
    [ Upstream commit 9f62c15f28b0d1d746734666d88a79f08ba1e43e ]
    
    Fix the following slab-out-of-bounds kasan report in
    ndisc_fill_redirect_hdr_option when the incoming ipv6 packet is not
    linear and the accessed data are not in the linear data region of orig_skb.
    
    [ 1503.122508] ==================================================================
    [ 1503.122832] BUG: KASAN: slab-out-of-bounds in ndisc_send_redirect+0x94e/0x990
    [ 1503.123036] Read of size 1184 at addr ffff8800298ab6b0 by task netperf/1932
    
    [ 1503.123220] CPU: 0 PID: 1932 Comm: netperf Not tainted 4.16.0-rc2+ #124
    [ 1503.123347] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
    [ 1503.123527] Call Trace:
    [ 1503.123579]  <IRQ>
    [ 1503.123638]  print_address_description+0x6e/0x280
    [ 1503.123849]  kasan_report+0x233/0x350
    [ 1503.123946]  memcpy+0x1f/0x50
    [ 1503.124037]  ndisc_send_redirect+0x94e/0x990
    [ 1503.125150]  ip6_forward+0x1242/0x13b0
    [...]
    [ 1503.153890] Allocated by task 1932:
    [ 1503.153982]  kasan_kmalloc+0x9f/0xd0
    [ 1503.154074]  __kmalloc_track_caller+0xb5/0x160
    [ 1503.154198]  __kmalloc_reserve.isra.41+0x24/0x70
    [ 1503.154324]  __alloc_skb+0x130/0x3e0
    [ 1503.154415]  sctp_packet_transmit+0x21a/0x1810
    [ 1503.154533]  sctp_outq_flush+0xc14/0x1db0
    [ 1503.154624]  sctp_do_sm+0x34e/0x2740
    [ 1503.154715]  sctp_primitive_SEND+0x57/0x70
    [ 1503.154807]  sctp_sendmsg+0xaa6/0x1b10
    [ 1503.154897]  sock_sendmsg+0x68/0x80
    [ 1503.154987]  ___sys_sendmsg+0x431/0x4b0
    [ 1503.155078]  __sys_sendmsg+0xa4/0x130
    [ 1503.155168]  do_syscall_64+0x171/0x3f0
    [ 1503.155259]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    [ 1503.155436] Freed by task 1932:
    [ 1503.155527]  __kasan_slab_free+0x134/0x180
    [ 1503.155618]  kfree+0xbc/0x180
    [ 1503.155709]  skb_release_data+0x27f/0x2c0
    [ 1503.155800]  consume_skb+0x94/0xe0
    [ 1503.155889]  sctp_chunk_put+0x1aa/0x1f0
    [ 1503.155979]  sctp_inq_pop+0x2f8/0x6e0
    [ 1503.156070]  sctp_assoc_bh_rcv+0x6a/0x230
    [ 1503.156164]  sctp_inq_push+0x117/0x150
    [ 1503.156255]  sctp_backlog_rcv+0xdf/0x4a0
    [ 1503.156346]  __release_sock+0x142/0x250
    [ 1503.156436]  release_sock+0x80/0x180
    [ 1503.156526]  sctp_sendmsg+0xbb0/0x1b10
    [ 1503.156617]  sock_sendmsg+0x68/0x80
    [ 1503.156708]  ___sys_sendmsg+0x431/0x4b0
    [ 1503.156799]  __sys_sendmsg+0xa4/0x130
    [ 1503.156889]  do_syscall_64+0x171/0x3f0
    [ 1503.156980]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    [ 1503.157158] The buggy address belongs to the object at ffff8800298ab600
                    which belongs to the cache kmalloc-1024 of size 1024
    [ 1503.157444] The buggy address is located 176 bytes inside of
                    1024-byte region [ffff8800298ab600, ffff8800298aba00)
    [ 1503.157702] The buggy address belongs to the page:
    [ 1503.157820] page:ffffea0000a62a00 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
    [ 1503.158053] flags: 0x4000000000008100(slab|head)
    [ 1503.158171] raw: 4000000000008100 0000000000000000 0000000000000000 00000001800e000e
    [ 1503.158350] raw: dead000000000100 dead000000000200 ffff880036002600 0000000000000000
    [ 1503.158523] page dumped because: kasan: bad access detected
    
    [ 1503.158698] Memory state around the buggy address:
    [ 1503.158816]  ffff8800298ab900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 1503.158988]  ffff8800298ab980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [ 1503.159165] >ffff8800298aba00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [ 1503.159338]                    ^
    [ 1503.159436]  ffff8800298aba80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [ 1503.159610]  ffff8800298abb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [ 1503.159785] ==================================================================
    [ 1503.159964] Disabling lock debugging due to kernel taint
    
    The test scenario to trigger the issue consists of 4 devices:
    - H0: data sender, connected to LAN0
    - H1: data receiver, connected to LAN1
    - GW0 and GW1: routers between LAN0 and LAN1. Both of them have an
      ethernet connection on LAN0 and LAN1
    On H{0,1} set GW0 as default gateway while on GW0 set GW1 as next hop for
    data from LAN0 to LAN1.
    Moreover create an ip6ip6 tunnel between H0 and H1 and send 3 concurrent
    data streams (TCP/UDP/SCTP) from H0 to H1 through ip6ip6 tunnel (send
    buffer size is set to 16K). While data streams are active flush the route
    cache on HA multiple times.
    I have not been able to identify a given commit that introduced the issue
    since, using the reproducer described above, the kasan report has been
    triggered from 4.14 and I have not gone back further.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 91d27e0c302501e148460db9981b5b04481781ce
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Tue Mar 6 22:57:01 2018 +0300

    dccp: check sk for closed state in dccp_sendmsg()
    
    
    [ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ]
    
    dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL,
    therefore if DCCP socket is disconnected and dccp_sendmsg() is
    called after it, it will cause a NULL pointer dereference in
    dccp_write_xmit().
    
    This crash and the reproducer was reported by syzbot. Looks like
    it is reproduced if commit 69c64866ce07 ("dccp: CVE-2017-8824:
    use-after-free in DCCP code") is applied.
    
    Reported-by: syzbot+f99ab3887ab65d70f816@syzkaller.appspotmail.com
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 946b9671ac02842c454f4da7b560feb9c84a4356
Author: Kirill Tkhai <ktkhai@virtuozzo.com>
Date:   Tue Mar 6 18:46:39 2018 +0300

    net: Fix hlist corruptions in inet_evict_bucket()
    
    
    [ Upstream commit a560002437d3646dafccecb1bf32d1685112ddda ]
    
    inet_evict_bucket() iterates global list, and
    several tasks may call it in parallel. All of
    them hash the same fq->list_evictor to different
    lists, which leads to list corruption.
    
    This patch makes fq be hashed to expired list
    only if this has not been made yet by another
    task. Since inet_frag_alloc() allocates fq
    using kmem_cache_zalloc(), we may rely on
    list_evictor is initially unhashed.
    
    The problem seems to exist before async
    pernet_operations, as there was possible to have
    exit method to be executed in parallel with
    inet_frags::frags_work, so I add two Fixes tags.
    This also may go to stable.
    
    Fixes: d1fe19444d82 "inet: frag: don't re-use chainlist for evictor"
    Fixes: f84c6821aa54 "net: Convert pernet_subsys, registered from inet_init()"
    Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ff5078b0396960c69718a41f916f81a6c59b074
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 14 09:04:16 2018 -0700

    net: use skb_to_full_sk() in skb_update_prio()
    
    
    [ Upstream commit 4dcb31d4649df36297296b819437709f5407059c ]
    
    Andrei Vagin reported a KASAN: slab-out-of-bounds error in
    skb_update_prio()
    
    Since SYNACK might be attached to a request socket, we need to
    get back to the listener socket.
    Since this listener is manipulated without locks, add const
    qualifiers to sock_cgroup_prioidx() so that the const can also
    be used in skb_update_prio()
    
    Also add the const qualifier to sock_cgroup_classid() for consistency.
    
    Fixes: ca6fb0651883 ("tcp: attach SYNACK messages to request sockets instead of listener")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrei Vagin <avagin@virtuozzo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6cdb675ca0a0f1e1913b48060414933dbd08565
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Mar 5 08:51:03 2018 -0800

    ieee802154: 6lowpan: fix possible NULL deref in lowpan_device_event()
    
    
    [ Upstream commit ca0edb131bdf1e6beaeb2b8289fd6b374b74147d ]
    
    A tun device type can trivially be set to arbitrary value using
    TUNSETLINK ioctl().
    
    Therefore, lowpan_device_event() must really check that ieee802154_ptr
    is not NULL.
    
    Fixes: 2c88b5283f60d ("ieee802154: 6lowpan: remove check on null")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Aring <alex.aring@gmail.com>
    Cc: Stefan Schmidt <stefan@osg.samsung.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Stefan Schmidt <stefan@osg.samsung.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f77ff13a06c1185491169b78e33bfb6a169a933c
Author: Alexey Kodanev <alexey.kodanev@oracle.com>
Date:   Mon Mar 5 20:52:54 2018 +0300

    sch_netem: fix skb leak in netem_enqueue()
    
    
    [ Upstream commit 35d889d10b649fda66121891ec05eca88150059d ]
    
    When we exceed current packets limit and we have more than one
    segment in the list returned by skb_gso_segment(), netem drops
    only the first one, skipping the rest, hence kmemleak reports:
    
    unreferenced object 0xffff880b5d23b600 (size 1024):
      comm "softirq", pid 0, jiffies 4384527763 (age 2770.629s)
      hex dump (first 32 bytes):
        00 80 23 5d 0b 88 ff ff 00 00 00 00 00 00 00 00  ..#]............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000d8a19b9d>] __alloc_skb+0xc9/0x520
        [<000000001709b32f>] skb_segment+0x8c8/0x3710
        [<00000000c7b9bb88>] tcp_gso_segment+0x331/0x1830
        [<00000000c921cba1>] inet_gso_segment+0x476/0x1370
        [<000000008b762dd4>] skb_mac_gso_segment+0x1f9/0x510
        [<000000002182660a>] __skb_gso_segment+0x1dd/0x620
        [<00000000412651b9>] netem_enqueue+0x1536/0x2590 [sch_netem]
        [<0000000005d3b2a9>] __dev_queue_xmit+0x1167/0x2120
        [<00000000fc5f7327>] ip_finish_output2+0x998/0xf00
        [<00000000d309e9d3>] ip_output+0x1aa/0x2c0
        [<000000007ecbd3a4>] tcp_transmit_skb+0x18db/0x3670
        [<0000000042d2a45f>] tcp_write_xmit+0x4d4/0x58c0
        [<0000000056a44199>] tcp_tasklet_func+0x3d9/0x540
        [<0000000013d06d02>] tasklet_action+0x1ca/0x250
        [<00000000fcde0b8b>] __do_softirq+0x1b4/0x5a3
        [<00000000e7ed027c>] irq_exit+0x1e2/0x210
    
    Fix it by adding the rest of the segments, if any, to skb 'to_free'
    list. Add new __qdisc_drop_all() and qdisc_drop_all() functions
    because they can be useful in the future if we need to drop segmented
    GSO packets in other places.
    
    Fixes: 6071bd1aa13e ("netem: Segment GSO packets on enqueue")
    Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 515bc34124f3aaf7ea2508fa2707906623eba748
Author: Tom Herbert <tom@quantonium.net>
Date:   Tue Mar 13 12:01:43 2018 -0700

    kcm: lock lower socket in kcm_attach
    
    
    [ Upstream commit 2cc683e88c0c993ac3721d9b702cb0630abe2879 ]
    
    Need to lock lower socket in order to provide mutual exclusion
    with kcm_unattach.
    
    v2: Add Reported-by for syzbot
    
    Fixes: ab7ac4eb9832e32a09f4e804 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: syzbot+ea75c0ffcd353d32515f064aaebefc5279e6161e@syzkaller.appspotmail.com
    Signed-off-by: Tom Herbert <tom@quantonium.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 07cf9d303c7ce8620ea34e3407e08facf65c732d
Author: Paul Blakey <paulb@mellanox.com>
Date:   Sun Mar 4 17:29:48 2018 +0200

    rhashtable: Fix rhlist duplicates insertion
    
    
    [ Upstream commit d3dcf8eb615537526bd42ff27a081d46d337816e ]
    
    When inserting duplicate objects (those with the same key),
    current rhlist implementation messes up the chain pointers by
    updating the bucket pointer instead of prev next pointer to the
    newly inserted node. This causes missing elements on removal and
    travesal.
    
    Fix that by properly updating pprev pointer to point to
    the correct rhash_head next pointer.
    
    Issue: 1241076
    Change-Id: I86b2c140bcb4aeb10b70a72a267ff590bb2b17e7
    Fixes: ca26893f05e8 ('rhashtable: Add rhlist interface')
    Signed-off-by: Paul Blakey <paulb@mellanox.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 090da7ced80b738e5ea0a055e8dc982740a951b5
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Tue Mar 20 16:49:26 2018 +0100

    ppp: avoid loop in xmit recursion detection code
    
    
    [ Upstream commit 6d066734e9f09cdea4a3b9cb76136db3f29cfb02 ]
    
    We already detect situations where a PPP channel sends packets back to
    its upper PPP device. While this is enough to avoid deadlocking on xmit
    locks, this doesn't prevent packets from looping between the channel
    and the unit.
    
    The problem is that ppp_start_xmit() enqueues packets in ppp->file.xq
    before checking for xmit recursion. Therefore, __ppp_xmit_process()
    might dequeue a packet from ppp->file.xq and send it on the channel
    which, in turn, loops it back on the unit. Then ppp_start_xmit()
    queues the packet back to ppp->file.xq and __ppp_xmit_process() picks
    it up and sends it again through the channel. Therefore, the packet
    will loop between __ppp_xmit_process() and ppp_start_xmit() until some
    other part of the xmit path drops it.
    
    For L2TP, we rapidly fill the skb's headroom and pppol2tp_xmit() drops
    the packet after a few iterations. But PPTP reallocates the headroom
    if necessary, letting the loop run and exhaust the machine resources
    (as reported in https://bugzilla.kernel.org/show_bug.cgi?id=199109).
    
    Fix this by letting __ppp_xmit_process() enqueue the skb to
    ppp->file.xq, so that we can check for recursion before adding it to
    the queue. Now ppp_xmit_process() can drop the packet when recursion is
    detected.
    
    __ppp_channel_push() is a bit special. It calls __ppp_xmit_process()
    without having any actual packet to send. This is used by
    ppp_output_wakeup() to re-enable transmission on the parent unit (for
    implementations like ppp_async.c, where the .start_xmit() function
    might not consume the skb, leaving it in ppp->xmit_pending and
    disabling transmission).
    Therefore, __ppp_xmit_process() needs to handle the case where skb is
    NULL, dequeuing as many packets as possible from ppp->file.xq.
    
    Reported-by: xu heng <xuheng333@zoho.com>
    Fixes: 55454a565836 ("ppp: avoid dealock on recursive xmit")
    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 28b488f7cb3a6af9f4512981b113f6e5d7e9752e
Author: Roman Mashak <mrv@mojatatu.com>
Date:   Mon Mar 12 16:20:58 2018 -0400

    net sched actions: return explicit error when tunnel_key mode is not specified
    
    
    [ Upstream commit 51d4740f88affd85d49c04e3c9cd129c0e33bcb9 ]
    
    If set/unset mode of the tunnel_key action is not provided, ->init() still
    returns 0, and the caller proceeds with bogus 'struct tc_action *' object,
    this results in crash:
    
    % tc actions add action tunnel_key src_ip 1.1.1.1 dst_ip 2.2.2.1 id 7 index 1
    
    [   35.805515] general protection fault: 0000 [#1] SMP PTI
    [   35.806161] Modules linked in: act_tunnel_key kvm_intel kvm irqbypass
    crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64
    crypto_simd glue_helper cryptd serio_raw
    [   35.808233] CPU: 1 PID: 428 Comm: tc Not tainted 4.16.0-rc4+ #286
    [   35.808929] RIP: 0010:tcf_action_init+0x90/0x190
    [   35.809457] RSP: 0018:ffffb8edc068b9a0 EFLAGS: 00010206
    [   35.810053] RAX: 1320c000000a0003 RBX: 0000000000000001 RCX: 0000000000000000
    [   35.810866] RDX: 0000000000000070 RSI: 0000000000007965 RDI: ffffb8edc068b910
    [   35.811660] RBP: ffffb8edc068b9d0 R08: 0000000000000000 R09: ffffb8edc068b808
    [   35.812463] R10: ffffffffc02bf040 R11: 0000000000000040 R12: ffffb8edc068bb38
    [   35.813235] R13: 0000000000000000 R14: 0000000000000000 R15: ffffb8edc068b910
    [   35.814006] FS:  00007f3d0d8556c0(0000) GS:ffff91d1dbc40000(0000)
    knlGS:0000000000000000
    [   35.814881] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   35.815540] CR2: 000000000043f720 CR3: 0000000019248001 CR4: 00000000001606a0
    [   35.816457] Call Trace:
    [   35.817158]  tc_ctl_action+0x11a/0x220
    [   35.817795]  rtnetlink_rcv_msg+0x23d/0x2e0
    [   35.818457]  ? __slab_alloc+0x1c/0x30
    [   35.819079]  ? __kmalloc_node_track_caller+0xb1/0x2b0
    [   35.819544]  ? rtnl_calcit.isra.30+0xe0/0xe0
    [   35.820231]  netlink_rcv_skb+0xce/0x100
    [   35.820744]  netlink_unicast+0x164/0x220
    [   35.821500]  netlink_sendmsg+0x293/0x370
    [   35.822040]  sock_sendmsg+0x30/0x40
    [   35.822508]  ___sys_sendmsg+0x2c5/0x2e0
    [   35.823149]  ? pagecache_get_page+0x27/0x220
    [   35.823714]  ? filemap_fault+0xa2/0x640
    [   35.824423]  ? page_add_file_rmap+0x108/0x200
    [   35.825065]  ? alloc_set_pte+0x2aa/0x530
    [   35.825585]  ? finish_fault+0x4e/0x70
    [   35.826140]  ? __handle_mm_fault+0xbc1/0x10d0
    [   35.826723]  ? __sys_sendmsg+0x41/0x70
    [   35.827230]  __sys_sendmsg+0x41/0x70
    [   35.827710]  do_syscall_64+0x68/0x120
    [   35.828195]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    [   35.828859] RIP: 0033:0x7f3d0ca4da67
    [   35.829331] RSP: 002b:00007ffc9f284338 EFLAGS: 00000246 ORIG_RAX:
    000000000000002e
    [   35.830304] RAX: ffffffffffffffda RBX: 00007ffc9f284460 RCX: 00007f3d0ca4da67
    [   35.831247] RDX: 0000000000000000 RSI: 00007ffc9f2843b0 RDI: 0000000000000003
    [   35.832167] RBP: 000000005aa6a7a9 R08: 0000000000000001 R09: 0000000000000000
    [   35.833075] R10: 00000000000005f1 R11: 0000000000000246 R12: 0000000000000000
    [   35.833997] R13: 00007ffc9f2884c0 R14: 0000000000000001 R15: 0000000000674640
    [   35.834923] Code: 24 30 bb 01 00 00 00 45 31 f6 eb 5e 8b 50 08 83 c2 07 83 e2
    fc 83 c2 70 49 8b 07 48 8b 40 70 48 85 c0 74 10 48 89 14 24 4c 89 ff <ff> d0 48
    8b 14 24 48 01 c2 49 01 d6 45 85 ed 74 05 41 83 47 2c
    [   35.837442] RIP: tcf_action_init+0x90/0x190 RSP: ffffb8edc068b9a0
    [   35.838291] ---[ end trace a095c06ee4b97a26 ]---
    
    Fixes: d0f6dd8a914f ("net/sched: Introduce act_tunnel_key")
    Signed-off-by: Roman Mashak <mrv@mojatatu.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2274d77c36752d80e3bc91eb289c601c3f3795d9
Author: Brad Mouring <brad.mouring@ni.com>
Date:   Thu Mar 8 16:23:03 2018 -0600

    net: phy: Tell caller result of phy_change()
    
    
    [ Upstream commit a2c054a896b8ac794ddcfc7c92e2dc7ec4ed4ed5 ]
    
    In 664fcf123a30e (net: phy: Threaded interrupts allow some simplification)
    the phy_interrupt system was changed to use a traditional threaded
    interrupt scheme instead of a workqueue approach.
    
    With this change, the phy status check moved into phy_change, which
    did not report back to the caller whether or not the interrupt was
    handled. This means that, in the case of a shared phy interrupt,
    only the first phydev's interrupt registers are checked (since
    phy_interrupt() would always return IRQ_HANDLED). This leads to
    interrupt storms when it is a secondary device that's actually the
    interrupt source.
    
    Signed-off-by: Brad Mouring <brad.mouring@ni.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42cf2a1e5ac4a8c4b66d89fe674e79a8d17f806a
Author: Ido Schimmel <idosch@mellanox.com>
Date:   Thu Mar 15 14:49:56 2018 +0200

    mlxsw: spectrum_buffers: Set a minimum quota for CPU port traffic
    
    
    [ Upstream commit bcdd5de80a2275f7879dc278bfc747f1caf94442 ]
    
    In commit 9ffcc3725f09 ("mlxsw: spectrum: Allow packets to be trapped
    from any PG") I fixed a problem where packets could not be trapped to
    the CPU due to exceeded shared buffer quotas. The mentioned commit
    explains the problem in detail.
    
    The problem was fixed by assigning a minimum quota for the CPU port and
    the traffic class used for scheduling traffic to the CPU.
    
    However, commit 117b0dad2d54 ("mlxsw: Create a different trap group list
    for each device") assigned different traffic classes to different
    packet types and rendered the fix useless.
    
    Fix the problem by assigning a minimum quota for the CPU port and all
    the traffic classes that are currently in use.
    
    Fixes: 117b0dad2d54 ("mlxsw: Create a different trap group list for each device")
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Reported-by: Eddie Shklaer <eddies@mellanox.com>
    Tested-by: Eddie Shklaer <eddies@mellanox.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 dbad5abd2b167a3e7b981e833fd7f21747e3b47b
Author: David Lebrun <dlebrun@google.com>
Date:   Tue Mar 20 14:44:55 2018 +0000

    ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
    
    
    [ Upstream commit 191f86ca8ef27f7a492fd1c03620498c6e94f0ac ]
    
    The seg6_build_state() function is called with RCU read lock held,
    so we cannot use GFP_KERNEL. This patch uses GFP_ATOMIC instead.
    
    [   92.770271] =============================
    [   92.770628] WARNING: suspicious RCU usage
    [   92.770921] 4.16.0-rc4+ #12 Not tainted
    [   92.771277] -----------------------------
    [   92.771585] ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section!
    [   92.772279]
    [   92.772279] other info that might help us debug this:
    [   92.772279]
    [   92.773067]
    [   92.773067] rcu_scheduler_active = 2, debug_locks = 1
    [   92.773514] 2 locks held by ip/2413:
    [   92.773765]  #0:  (rtnl_mutex){+.+.}, at: [<00000000e5461720>] rtnetlink_rcv_msg+0x441/0x4d0
    [   92.774377]  #1:  (rcu_read_lock){....}, at: [<00000000df4f161e>] lwtunnel_build_state+0x59/0x210
    [   92.775065]
    [   92.775065] stack backtrace:
    [   92.775371] CPU: 0 PID: 2413 Comm: ip Not tainted 4.16.0-rc4+ #12
    [   92.775791] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
    [   92.776608] Call Trace:
    [   92.776852]  dump_stack+0x7d/0xbc
    [   92.777130]  __schedule+0x133/0xf00
    [   92.777393]  ? unwind_get_return_address_ptr+0x50/0x50
    [   92.777783]  ? __sched_text_start+0x8/0x8
    [   92.778073]  ? rcu_is_watching+0x19/0x30
    [   92.778383]  ? kernel_text_address+0x49/0x60
    [   92.778800]  ? __kernel_text_address+0x9/0x30
    [   92.779241]  ? unwind_get_return_address+0x29/0x40
    [   92.779727]  ? pcpu_alloc+0x102/0x8f0
    [   92.780101]  _cond_resched+0x23/0x50
    [   92.780459]  __mutex_lock+0xbd/0xad0
    [   92.780818]  ? pcpu_alloc+0x102/0x8f0
    [   92.781194]  ? seg6_build_state+0x11d/0x240
    [   92.781611]  ? save_stack+0x9b/0xb0
    [   92.781965]  ? __ww_mutex_wakeup_for_backoff+0xf0/0xf0
    [   92.782480]  ? seg6_build_state+0x11d/0x240
    [   92.782925]  ? lwtunnel_build_state+0x1bd/0x210
    [   92.783393]  ? ip6_route_info_create+0x687/0x1640
    [   92.783846]  ? ip6_route_add+0x74/0x110
    [   92.784236]  ? inet6_rtm_newroute+0x8a/0xd0
    
    Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Signed-off-by: David Lebrun <dlebrun@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cb4963b49426fb6d86fde623366460dadac2908e
Author: David Lebrun <dlebrun@google.com>
Date:   Tue Mar 20 14:44:56 2018 +0000

    ipv6: sr: fix NULL pointer dereference when setting encap source address
    
    
    [ Upstream commit 8936ef7604c11b5d701580d779e0f5684abc7b68 ]
    
    When using seg6 in encap mode, we call ipv6_dev_get_saddr() to set the
    source address of the outer IPv6 header, in case none was specified.
    Using skb->dev can lead to BUG() when it is in an inconsistent state.
    This patch uses the net_device attached to the skb's dst instead.
    
    [940807.667429] BUG: unable to handle kernel NULL pointer dereference at 000000000000047c
    [940807.762427] IP: ipv6_dev_get_saddr+0x8b/0x1d0
    [940807.815725] PGD 0 P4D 0
    [940807.847173] Oops: 0000 [#1] SMP PTI
    [940807.890073] Modules linked in:
    [940807.927765] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G        W        4.16.0-rc1-seg6bpf+ #2
    [940808.028988] Hardware name: HP ProLiant DL120 G6/ProLiant DL120 G6, BIOS O26    09/06/2010
    [940808.128128] RIP: 0010:ipv6_dev_get_saddr+0x8b/0x1d0
    [940808.187667] RSP: 0018:ffff88043fd836b0 EFLAGS: 00010206
    [940808.251366] RAX: 0000000000000005 RBX: ffff88042cb1c860 RCX: 00000000000000fe
    [940808.338025] RDX: 00000000000002c0 RSI: ffff88042cb1c860 RDI: 0000000000004500
    [940808.424683] RBP: ffff88043fd83740 R08: 0000000000000000 R09: ffffffffffffffff
    [940808.511342] R10: 0000000000000040 R11: 0000000000000000 R12: ffff88042cb1c850
    [940808.598012] R13: ffffffff8208e380 R14: ffff88042ac8da00 R15: 0000000000000002
    [940808.684675] FS:  0000000000000000(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
    [940808.783036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [940808.852975] CR2: 000000000000047c CR3: 00000004255fe000 CR4: 00000000000006e0
    [940808.939634] Call Trace:
    [940808.970041]  <IRQ>
    [940808.995250]  ? ip6t_do_table+0x265/0x640
    [940809.043341]  seg6_do_srh_encap+0x28f/0x300
    [940809.093516]  ? seg6_do_srh+0x1a0/0x210
    [940809.139528]  seg6_do_srh+0x1a0/0x210
    [940809.183462]  seg6_output+0x28/0x1e0
    [940809.226358]  lwtunnel_output+0x3f/0x70
    [940809.272370]  ip6_xmit+0x2b8/0x530
    [940809.313185]  ? ac6_proc_exit+0x20/0x20
    [940809.359197]  inet6_csk_xmit+0x7d/0xc0
    [940809.404173]  tcp_transmit_skb+0x548/0x9a0
    [940809.453304]  __tcp_retransmit_skb+0x1a8/0x7a0
    [940809.506603]  ? ip6_default_advmss+0x40/0x40
    [940809.557824]  ? tcp_current_mss+0x24/0x90
    [940809.605925]  tcp_retransmit_skb+0xd/0x80
    [940809.654016]  tcp_xmit_retransmit_queue.part.17+0xf9/0x210
    [940809.719797]  tcp_ack+0xa47/0x1110
    [940809.760612]  tcp_rcv_established+0x13c/0x570
    [940809.812865]  tcp_v6_do_rcv+0x151/0x3d0
    [940809.858879]  tcp_v6_rcv+0xa5c/0xb10
    [940809.901770]  ? seg6_output+0xdd/0x1e0
    [940809.946745]  ip6_input_finish+0xbb/0x460
    [940809.994837]  ip6_input+0x74/0x80
    [940810.034612]  ? ip6_rcv_finish+0xb0/0xb0
    [940810.081663]  ipv6_rcv+0x31c/0x4c0
    ...
    
    Fixes: 6c8702c60b886 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
    Reported-by: Tom Herbert <tom@quantonium.net>
    Signed-off-by: David Lebrun <dlebrun@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5defa8c9269a4c5e7b284631e9a60abe1d57f20b
Author: Stefano Brivio <sbrivio@redhat.com>
Date:   Mon Mar 19 11:24:58 2018 +0100

    ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
    
    
    [ Upstream commit 5f2fb802eee1df0810b47ea251942fe3fd36589a ]
    
    Fixes: 2f987a76a977 ("net: ipv6: keep sk status consistent after datagram connect failure")
    Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Acked-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 a8f02befc87d6f1a882c9b14a31bcfa1fbd3d430
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Mar 12 14:54:23 2018 +0100

    net: ipv6: keep sk status consistent after datagram connect failure
    
    
    [ Upstream commit 2f987a76a97773beafbc615b9c4d8fe79129a7f4 ]
    
    On unsuccesful ip6_datagram_connect(), if the failure is caused by
    ip6_datagram_dst_update(), the sk peer information are cleared, but
    the sk->sk_state is preserved.
    
    If the socket was already in an established status, the overall sk
    status is inconsistent and fouls later checks in datagram code.
    
    Fix this saving the old peer information and restoring them in
    case of failure. This also aligns ipv6 datagram connect() behavior
    with ipv4.
    
    v1 -> v2:
     - added missing Fixes tag
    
    Fixes: 85cb73ff9b74 ("net: ipv6: reset daddr and dport in sk if connect() fails")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 82fb817863e3a853715e8cc606ea4ed37b9a55ce
Author: Shannon Nelson <shannon.nelson@oracle.com>
Date:   Thu Mar 8 16:17:23 2018 -0800

    macvlan: filter out unsupported feature flags
    
    
    [ Upstream commit 13fbcc8dc573482dd3f27568257fd7087f8935f4 ]
    
    Adding a macvlan device on top of a lowerdev that supports
    the xfrm offloads fails with a new regression:
      # ip link add link ens1f0 mv0 type macvlan
      RTNETLINK answers: Operation not permitted
    
    Tracing down the failure shows that the macvlan device inherits
    the NETIF_F_HW_ESP and NETIF_F_HW_ESP_TX_CSUM feature flags
    from the lowerdev, but with no dev->xfrmdev_ops API filled
    in, it doesn't actually support xfrm.  When the request is
    made to add the new macvlan device, the XFRM listener for
    NETDEV_REGISTER calls xfrm_api_check() which fails the new
    registration because dev->xfrmdev_ops is NULL.
    
    The macvlan creation succeeds when we filter out the ESP
    feature flags in macvlan_fix_features(), so let's filter them
    out like we're already filtering out ~NETIF_F_NETNS_LOCAL.
    When XFRM support is added in the future, we can add the flags
    into MACVLAN_FEATURES.
    
    This same problem could crop up in the future with any other
    new feature flags, so let's filter out any flags that aren't
    defined as supported in macvlan.
    
    Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API")
    Reported-by: Alexey Kodanev <alexey.kodanev@oracle.com>
    Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b51eb57dac9cbd09e1ad3b1aed68ea11bcb83743
Author: Arkadi Sharshevsky <arkadis@mellanox.com>
Date:   Sun Mar 18 17:37:22 2018 +0200

    devlink: Remove redundant free on error path
    
    
    [ Upstream commit 7fe4d6dcbcb43fe0282d4213fc52be178bb30e91 ]
    
    The current code performs unneeded free. Remove the redundant skb freeing
    during the error path.
    
    Fixes: 1555d204e743 ("devlink: Support for pipeline debug (dpipe)")
    Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.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 67a1dc5675670f17a77a0ac65f688d4b5adeeefa
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Fri Mar 16 17:08:35 2018 -0500

    net: phy: relax error checking when creating sysfs link netdev->phydev
    
    
    [ Upstream commit 4414b3ed74be0e205e04e12cd83542a727d88255 ]
    
    Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
    one netdevice, as result such drivers will produce warning during system
    boot and fail to connect second phy to netdevice when PHYLIB framework
    will try to create sysfs link netdev->phydev for second PHY
    in phy_attach_direct(), because sysfs link with the same name has been
    created already for the first PHY. As result, second CPSW external
    port will became unusable.
    
    Fix it by relaxing error checking when PHYLIB framework is creating sysfs
    link netdev->phydev in phy_attach_direct(), suppressing warning by using
    sysfs_create_link_nowarn() and adding error message instead.
    After this change links (phy->netdev and netdev->phy) creation failure is not
    fatal any more and system can continue working, which fixes TI CPSW issue.
    
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 223c542442527ca04cfd9843450ca103b822e558
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Fri Mar 16 17:08:34 2018 -0500

    sysfs: symlink: export sysfs_create_link_nowarn()
    
    
    [ Upstream commit 2399ac42e762ab25c58420e25359b2921afdc55f ]
    
    The sysfs_create_link_nowarn() is going to be used in phylib framework in
    subsequent patch which can be built as module. Hence, export
    sysfs_create_link_nowarn() to avoid build errors.
    
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")
    Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 497166d63780f0a7835f14d9cebb40cf098b1c55
Author: Michal Kalderon <Michal.Kalderon@cavium.com>
Date:   Wed Mar 14 14:49:28 2018 +0200

    qed: Fix non TCP packets should be dropped on iWARP ll2 connection
    
    
    [ Upstream commit 16da09047d3fb991dc48af41f6d255fd578e8ca2 ]
    
    FW workaround. The iWARP LL2 connection did not expect TCP packets
    to arrive on it's connection. The fix drops any non-tcp packets
    
    Fixes b5c29ca ("qed: iWARP CM - setup a ll2 connection for handling
    SYN packets")
    
    Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
    Signed-off-by: Ariel Elior <Ariel.Elior@cavium.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e44c1733059c69868e81f82eb09fcb6bbc492050
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Tue Mar 6 17:15:12 2018 -0500

    tcp: purge write queue upon aborting the connection
    
    
    [ Upstream commit e05836ac07c77dd90377f8c8140bce2a44af5fe7 ]
    
    When the connection is aborted, there is no point in
    keeping the packets on the write queue until the connection
    is closed.
    
    Similar to a27fd7a8ed38 ('tcp: purge write queue upon RST'),
    this is essential for a correct MSG_ZEROCOPY implementation,
    because userspace cannot call close(fd) before receiving
    zerocopy signals even when the connection is aborted.
    
    Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-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 dbbf2d1e4077bab0c65ece2765d3fc69cf7d610f
Author: Soheil Hassas Yeganeh <soheil@google.com>
Date:   Thu Mar 15 12:09:13 2018 -0400

    tcp: reset sk_send_head in tcp_write_queue_purge
    
    
    tcp_write_queue_purge clears all the SKBs in the write queue
    but does not reset the sk_send_head. As a result, we can have
    a NULL pointer dereference anywhere that we use tcp_send_head
    instead of the tcp_write_queue_tail.
    
    For example, after a27fd7a8ed38 (tcp: purge write queue upon RST),
    we can purge the write queue on RST. Prior to
    75c119afe14f (tcp: implement rb-tree based retransmit queue),
    tcp_push will only check tcp_send_head and then accesses
    tcp_write_queue_tail to send the actual SKB. As a result, it will
    dereference a NULL pointer.
    
    This has been reported twice for 4.14 where we don't have
    75c119afe14f:
    
    By Timofey Titovets:
    
    [  422.081094] BUG: unable to handle kernel NULL pointer dereference
    at 0000000000000038
    [  422.081254] IP: tcp_push+0x42/0x110
    [  422.081314] PGD 0 P4D 0
    [  422.081364] Oops: 0002 [#1] SMP PTI
    
    By Yongjian Xu:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
    IP: tcp_push+0x48/0x120
    PGD 80000007ff77b067 P4D 80000007ff77b067 PUD 7fd989067 PMD 0
    Oops: 0002 [#18] SMP PTI
    Modules linked in: tcp_diag inet_diag tcp_bbr sch_fq iTCO_wdt
    iTCO_vendor_support pcspkr ixgbe mdio i2c_i801 lpc_ich joydev input_leds shpchp
    e1000e igb dca ptp pps_core hwmon mei_me mei ipmi_si ipmi_msghandler sg ses
    scsi_transport_sas enclosure ext4 jbd2 mbcache sd_mod ahci libahci megaraid_sas
    wmi ast ttm dm_mirror dm_region_hash dm_log dm_mod dax
    CPU: 6 PID: 14156 Comm: [ET_NET 6] Tainted: G D 4.14.26-1.el6.x86_64 #1
    Hardware name: LENOVO ThinkServer RD440 /ThinkServer RD440, BIOS A0TS80A
    09/22/2014
    task: ffff8807d78d8140 task.stack: ffffc9000e944000
    RIP: 0010:tcp_push+0x48/0x120
    RSP: 0018:ffffc9000e947a88 EFLAGS: 00010246
    RAX: 00000000000005b4 RBX: ffff880f7cce9c00 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff8807d00f5000
    RBP: ffffc9000e947aa8 R08: 0000000000001c84 R09: 0000000000000000
    R10: ffff8807d00f5158 R11: 0000000000000000 R12: ffff8807d00f5000
    R13: 0000000000000020 R14: 00000000000256d4 R15: 0000000000000000
    FS: 00007f5916de9700(0000) GS:ffff88107fd00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000038 CR3: 00000007f8226004 CR4: 00000000001606e0
    Call Trace:
    tcp_sendmsg_locked+0x33d/0xe50
    tcp_sendmsg+0x37/0x60
    inet_sendmsg+0x39/0xc0
    sock_sendmsg+0x49/0x60
    sock_write_iter+0xb6/0x100
    do_iter_readv_writev+0xec/0x130
    ? rw_verify_area+0x49/0xb0
    do_iter_write+0x97/0xd0
    vfs_writev+0x7e/0xe0
    ? __wake_up_common_lock+0x80/0xa0
    ? __fget_light+0x2c/0x70
    ? __do_page_fault+0x1e7/0x530
    do_writev+0x60/0xf0
    ? inet_shutdown+0xac/0x110
    SyS_writev+0x10/0x20
    do_syscall_64+0x6f/0x140
    ? prepare_exit_to_usermode+0x8b/0xa0
    entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    RIP: 0033:0x3135ce0c57
    RSP: 002b:00007f5916de4b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000003135ce0c57
    RDX: 0000000000000002 RSI: 00007f5916de4b90 RDI: 000000000000606f
    RBP: 0000000000000000 R08: 0000000000000000 R09: 00007f5916de8c38
    R10: 0000000000000000 R11: 0000000000000293 R12: 00000000000464cc
    R13: 00007f5916de8c30 R14: 00007f58d8bef080 R15: 0000000000000002
    Code: 48 8b 97 60 01 00 00 4c 8d 97 58 01 00 00 41 b9 00 00 00 00 41 89 f3 4c 39
    d2 49 0f 44 d1 41 81 e3 00 80 00 00 0f 85 b0 00 00 00 <80> 4a 38 08 44 8b 8f 74
    06 00 00 44 89 8f 7c 06 00 00 83 e6 01
    RIP: tcp_push+0x48/0x120 RSP: ffffc9000e947a88
    CR2: 0000000000000038
    ---[ end trace 8d545c2e93515549 ]---
    
    Fixes: a27fd7a8ed38 (tcp: purge write queue upon RST)
    Reported-by: Timofey Titovets <nefelim4ag@gmail.com>
    Reported-by: Yongjian Xu <yongjianchn@gmail.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
    Tested-by: Yongjian Xu <yongjianchn@gmail.com>
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>