commit fd1594eb706427cc0d88fdfc2c1dbecd5abe7a83
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 4 08:01:31 2019 +0200

    Linux 5.0.21

commit 0b2265ad7ba8955233936bdfdb49046ce0dcf8ea
Author: Junwei Hu <hujunwei4@huawei.com>
Date:   Mon May 20 14:43:59 2019 +0800

    tipc: fix modprobe tipc failed after switch order of device registration
    
    commit 526f5b851a96566803ee4bee60d0a34df56c77f8 upstream.
    
    Error message printed:
    modprobe: ERROR: could not insert 'tipc': Address family not
    supported by protocol.
    when modprobe tipc after the following patch: switch order of
    device registration, commit 7e27e8d6130c
    ("tipc: switch order of device registration to fix a crash")
    
    Because sock_create_kern(net, AF_TIPC, ...) called by
    tipc_topsrv_create_listener() in the initialization process
    of tipc_init_net(), so tipc_socket_init() must be execute before that.
    Meanwhile, tipc_net_id need to be initialized when sock_create()
    called, and tipc_socket_init() is no need to be called for each namespace.
    
    I add a variable tipc_topsrv_net_ops, and split the
    register_pernet_subsys() of tipc into two parts, and split
    tipc_socket_init() with initialization of pernet params.
    
    By the way, I fixed resources rollback error when tipc_bcast_init()
    failed in tipc_init_net().
    
    Fixes: 7e27e8d6130c ("tipc: switch order of device registration to fix a crash")
    Signed-off-by: Junwei Hu <hujunwei4@huawei.com>
    Reported-by: Wang Wang <wangwang2@huawei.com>
    Reported-by: syzbot+1e8114b61079bfe9cbc5@syzkaller.appspotmail.com
    Reviewed-by: Kang Zhou <zhoukang7@huawei.com>
    Reviewed-by: Suanming Mou <mousuanming@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9d39b8878fe5079f44e12c9f4c7c7a4fc804d5c4
Author: David S. Miller <davem@davemloft.net>
Date:   Fri May 17 12:15:05 2019 -0700

    Revert "tipc: fix modprobe tipc failed after switch order of device registration"
    
    commit 5593530e56943182ebb6d81eca8a3be6db6dbba4 upstream.
    
    This reverts commit 532b0f7ece4cb2ffd24dc723ddf55242d1188e5e.
    
    More revisions coming up.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e9df93ef30f8e0314b4f5b4567681dee2abd4d9
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Feb 13 18:21:31 2019 -0500

    xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
    
    commit 7681f31ec9cdacab4fd10570be924f2cef6669ba upstream.
    
    There is no need for this at all. Worst it means that if
    the guest tries to write to BARs it could lead (on certain
    platforms) to PCI SERR errors.
    
    Please note that with af6fc858a35b90e89ea7a7ee58e66628c55c776b
    "xen-pciback: limit guest control of command register"
    a guest is still allowed to enable those control bits (safely), but
    is not allowed to disable them and that therefore a well behaved
    frontend which enables things before using them will still
    function correctly.
    
    This is done via an write to the configuration register 0x4 which
    triggers on the backend side:
    command_write
      \- pci_enable_device
         \- pci_enable_device_flags
            \- do_pci_enable_device
               \- pcibios_enable_device
                  \-pci_enable_resourcess
                    [which enables the PCI_COMMAND_MEMORY|PCI_COMMAND_IO]
    
    However guests (and drivers) which don't do this could cause
    problems, including the security issues which XSA-120 sought
    to address.
    
    Reported-by: Jan Beulich <jbeulich@suse.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Prarit Bhargava <prarit@redhat.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92ae27ebd10ee995c65917e70fb96b81970bf442
Author: Daniel Axtens <dja@axtens.net>
Date:   Fri May 17 01:40:02 2019 +1000

    crypto: vmx - ghash: do nosimd fallback manually
    
    commit 357d065a44cdd77ed5ff35155a989f2a763e96ef upstream.
    
    VMX ghash was using a fallback that did not support interleaving simd
    and nosimd operations, leading to failures in the extended test suite.
    
    If I understood correctly, Eric's suggestion was to use the same
    data format that the generic code uses, allowing us to call into it
    with the same contexts. I wasn't able to get that to work - I think
    there's a very different key structure and data layout being used.
    
    So instead steal the arm64 approach and perform the fallback
    operations directly if required.
    
    Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
    Cc: stable@vger.kernel.org # v4.1+
    Reported-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Tested-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Daniel Axtens <dja@axtens.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1e6fe92e3a125812cbfb874713a72f25439d0a04
Author: Willem de Bruijn <willemb@google.com>
Date:   Thu May 30 18:01:21 2019 -0400

    net: correct zerocopy refcnt with udp MSG_MORE
    
    [ Upstream commit 100f6d8e09905c59be45b6316f8f369c0be1b2d8 ]
    
    TCP zerocopy takes a uarg reference for every skb, plus one for the
    tcp_sendmsg_locked datapath temporarily, to avoid reaching refcnt zero
    as it builds, sends and frees skbs inside its inner loop.
    
    UDP and RAW zerocopy do not send inside the inner loop so do not need
    the extra sock_zerocopy_get + sock_zerocopy_put pair. Commit
    52900d22288ed ("udp: elide zerocopy operation in hot path") introduced
    extra_uref to pass the initial reference taken in sock_zerocopy_alloc
    to the first generated skb.
    
    But, sock_zerocopy_realloc takes this extra reference at the start of
    every call. With MSG_MORE, no new skb may be generated to attach the
    extra_uref to, so refcnt is incorrectly 2 with only one skb.
    
    Do not take the extra ref if uarg && !tcp, which implies MSG_MORE.
    Update extra_uref accordingly.
    
    This conditional assignment triggers a false positive may be used
    uninitialized warning, so have to initialize extra_uref at define.
    
    Changes v1->v2: fix typo in Fixes SHA1
    
    Fixes: 52900d22288e7 ("udp: elide zerocopy operation in hot path")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Diagnosed-by: Eric Dumazet <edumazet@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 3ef160ce021902e979c575a04655623a209c668f
Author: Vishal Kulkarni <vishal@chelsio.com>
Date:   Thu May 23 08:07:21 2019 +0530

    cxgb4: Revert "cxgb4: Remove SGE_HOST_PAGE_SIZE dependency on page size"
    
    [ Upstream commit ab0610efabb4c4f419a531455708caf1dd29357e ]
    
    This reverts commit 2391b0030e241386d710df10e53e2cfc3c5d4fc1 which has
    introduced regression. Now SGE's BAR2 Doorbell/GTS Page Size is
    interpreted correctly in the firmware itself by using actual host
    page size. Hence previous commit needs to be reverted.
    
    Signed-off-by: Vishal Kulkarni <vishal@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 446051af00e0bcdf74ab4463ddf5e1b1bf93aa08
Author: Jakub Kicinski <jakub.kicinski@netronome.com>
Date:   Tue May 21 19:02:02 2019 -0700

    net/tls: don't ignore netdev notifications if no TLS features
    
    [ Upstream commit c3f4a6c39cf269a40d45f813c05fa830318ad875 ]
    
    On device surprise removal path (the notifier) we can't
    bail just because the features are disabled.  They may
    have been enabled during the lifetime of the device.
    This bug leads to leaking netdev references and
    use-after-frees if there are active connections while
    device features are cleared.
    
    Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a7c06b38ccfb1776798a77f0c8a2dfd27290fed
Author: Jakub Kicinski <jakub.kicinski@netronome.com>
Date:   Tue May 21 19:02:01 2019 -0700

    net/tls: fix state removal with feature flags off
    
    [ Upstream commit 3686637e507b48525fcea6fb91e1988bdbc14530 ]
    
    TLS offload drivers shouldn't (and currently don't) block
    the TLS offload feature changes based on whether there are
    active offloaded connections or not.
    
    This seems to be a good idea, because we want the admin to
    be able to disable the TLS offload at any time, and there
    is no clean way of disabling it for active connections
    (TX side is quite problematic).  So if features are cleared
    existing connections will stay offloaded until they close,
    and new connections will not attempt offload to a given
    device.
    
    However, the offload state removal handling is currently
    broken if feature flags get cleared while there are
    active TLS offloads.
    
    RX side will completely bail from cleanup, even on normal
    remove path, leaving device state dangling, potentially
    causing issues when the 5-tuple is reused.  It will also
    fail to release the netdev reference.
    
    Remove the RX-side warning message, in next release cycle
    it should be printed when features are disabled, rather
    than when connection dies, but for that we need a more
    efficient method of finding connection of a given netdev
    (a'la BPF offload code).
    
    Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d05866b416b2ed89977fee0842bb93ff96609fcf
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed May 22 19:12:56 2019 -0400

    bnxt_en: Reduce memory usage when running in kdump kernel.
    
    [ Upstream commit d629522e1d66561f38e5c8d4f52bb6d254ec0707 ]
    
    Skip RDMA context memory allocations, reduce to 1 ring, and disable
    TPA when running in the kdump kernel.  Without this patch, the driver
    fails to initialize with memory allocation errors when running in a
    typical kdump kernel.
    
    Fixes: cf6daed098d1 ("bnxt_en: Increase context memory allocations on 57500 chips for RDMA.")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a49d1ccac97429e8864149ea7423c5f66ffa8b98
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed May 22 19:12:55 2019 -0400

    bnxt_en: Fix possible BUG() condition when calling pci_disable_msix().
    
    [ Upstream commit 1b3f0b75c39f534278a895c117282014e9d0ae1f ]
    
    When making configuration changes, the driver calls bnxt_close_nic()
    and then bnxt_open_nic() for the changes to take effect.  A parameter
    irq_re_init is passed to the call sequence to indicate if IRQ
    should be re-initialized.  This irq_re_init parameter needs to
    be included in the bnxt_reserve_rings() call.  bnxt_reserve_rings()
    can only call pci_disable_msix() if the irq_re_init parameter is
    true, otherwise it may hit BUG() because some IRQs may not have been
    freed yet.
    
    Fixes: 41e8d7983752 ("bnxt_en: Modify the ring reservation functions for 57500 series chips.")
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8a645c42eb57fa2890bf8bdc42cec64d7756c19
Author: Michael Chan <michael.chan@broadcom.com>
Date:   Wed May 22 19:12:54 2019 -0400

    bnxt_en: Fix aggregation buffer leak under OOM condition.
    
    [ Upstream commit 296d5b54163964b7ae536b8b57dfbd21d4e868e1 ]
    
    For every RX packet, the driver replenishes all buffers used for that
    packet and puts them back into the RX ring and RX aggregation ring.
    In one code path where the RX packet has one RX buffer and one or more
    aggregation buffers, we missed recycling the aggregation buffer(s) if
    we are unable to allocate a new SKB buffer.  This leads to the
    aggregation ring slowly running out of buffers over time.  Fix it
    by properly recycling the aggregation buffers.
    
    Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
    Reported-by: Rakesh Hemnani <rhemnani@fb.com>
    Signed-off-by: Michael Chan <michael.chan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a2d02301d7b69f19e3afcba38f61b7d571f39a2
Author: Weifeng Voon <weifeng.voon@intel.com>
Date:   Tue May 21 13:38:38 2019 +0800

    net: stmmac: dma channel control register need to be init first
    
    stmmac_init_chan() needs to be called before stmmac_init_rx_chan() and
    stmmac_init_tx_chan(). This is because if PBLx8 is to be used,
    "DMA_CH(#i)_Control.PBLx8" needs to be set before programming
    "DMA_CH(#i)_TX_Control.TxPBL" and "DMA_CH(#i)_RX_Control.RxPBL".
    
    Fixes: 47f2a9ce527a ("net: stmmac: dma channel init prepared for multiple queues")
    Reviewed-by: Zhang, Baoli <baoli.zhang@intel.com>
    Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Weifeng Voon <weifeng.voon@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d54fa13b3a1b706ca9f4c23a2127f43f5904abd
Author: Tan, Tee Min <tee.min.tan@intel.com>
Date:   Tue May 21 12:55:42 2019 +0800

    net: stmmac: fix ethtool flow control not able to get/set
    
    Currently ethtool was not able to get/set the flow control due to a
    missing "!". It will always return -EOPNOTSUPP even the device is
    flow control supported.
    
    This patch fixes the condition check for ethtool flow control get/set
    function for ETHTOOL_LINK_MODE_Asym_Pause_BIT.
    
    Fixes: 3c1bcc8614db (“net: ethernet: Convert phydev advertize and supported from u32 to link mode”)
    Signed-off-by: Tan, Tee Min <tee.min.tan@intel.com>
    Reviewed-by: Ong Boon Leong <boon.leong.ong@intel.com>
    Signed-off-by: Voon, Weifeng <weifeng.voon@intel.com@intel.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit afb01d9cbbb3cf105828e5f711448a22353c8160
Author: Saeed Mahameed <saeedm@mellanox.com>
Date:   Thu May 23 12:55:10 2019 -0700

    net/mlx5e: Disable rxhash when CQE compress is enabled
    
    [ Upstream commit c0194e2d0ef0e5ce5e21a35640d23a706827ae28 ]
    
    When CQE compression is enabled (Multi-host systems), compressed CQEs
    might arrive to the driver rx, compressed CQEs don't have a valid hash
    offload and the driver already reports a hash value of 0 and invalid hash
    type on the skb for compressed CQEs, but this is not good enough.
    
    On a congested PCIe, where CQE compression will kick in aggressively,
    gro will deliver lots of out of order packets due to the invalid hash
    and this might cause a serious performance drop.
    
    The only valid solution, is to disable rxhash offload at all when CQE
    compression is favorable (Multi-host systems).
    
    Fixes: 7219ab34f184 ("net/mlx5e: CQE compression")
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28a69736eb9432bdd2ee0fad659a40c5fe6bb6c4
Author: Parav Pandit <parav@mellanox.com>
Date:   Fri May 10 10:40:08 2019 -0500

    net/mlx5: Allocate root ns memory using kzalloc to match kfree
    
    [ Upstream commit 25fa506b70cadb580c1e9cbd836d6417276d4bcd ]
    
    root ns is yet another fs core node which is freed using kfree() by
    tree_put_node().
    Rest of the other fs core objects are also allocated using kmalloc
    variants.
    
    However, root ns memory is allocated using kvzalloc().
    Hence allocate root ns memory using kzalloc().
    
    Fixes: 2530236303d9e ("net/mlx5_core: Flow steering tree initialization")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92c0f89774e0c6c82378e7cffd83751233559685
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Mon May 20 15:45:36 2019 +1200

    tipc: Avoid copying bytes beyond the supplied data
    
    TLV_SET is called with a data pointer and a len parameter that tells us
    how many bytes are pointed to by data. When invoking memcpy() we need
    to careful to only copy len bytes.
    
    Previously we would copy TLV_LENGTH(len) bytes which would copy an extra
    4 bytes past the end of the data pointer which newer GCC versions
    complain about.
    
     In file included from test.c:17:
     In function 'TLV_SET',
         inlined from 'test' at test.c:186:5:
     /usr/include/linux/tipc_config.h:317:3:
     warning: 'memcpy' forming offset [33, 36] is out of the bounds [0, 32]
     of object 'bearer_name' with type 'char[32]' [-Warray-bounds]
         memcpy(TLV_DATA(tlv_ptr), data, tlv_len);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     test.c: In function 'test':
     test.c::161:10: note:
     'bearer_name' declared here
         char bearer_name[TIPC_MAX_BEARER_NAME];
              ^~~~~~~~~~~
    
    We still want to ensure any padding bytes at the end are initialised, do
    this with a explicit memset() rather than copy bytes past the end of
    data. Apply the same logic to TCM_SET.
    
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fc37e5f538cfe34c612c6c6729912866f730cfe
Author: Parav Pandit <parav@mellanox.com>
Date:   Fri May 10 10:26:23 2019 -0500

    net/mlx5: Avoid double free in fs init error unwinding path
    
    [ Upstream commit 9414277a5df3669c67e818708c0f881597e0118e ]
    
    In below code flow, for ingress acl table root ns memory leads
    to double free.
    
    mlx5_init_fs
      init_ingress_acls_root_ns()
        init_ingress_acl_root_ns
           kfree(steering->esw_ingress_root_ns);
           /* steering->esw_ingress_root_ns is not marked NULL */
      mlx5_cleanup_fs
        cleanup_ingress_acls_root_ns
           steering->esw_ingress_root_ns non NULL check passes.
           kfree(steering->esw_ingress_root_ns);
           /* double free */
    
    Similar issue exist for other tables.
    
    Hence zero out the pointers to not process the table again.
    
    Fixes: 9b93ab981e3bf ("net/mlx5: Separate ingress/egress namespaces for each vport")
    Fixes: 40c3eebb49e51 ("net/mlx5: Add support in RDMA RX steering")
    Signed-off-by: Parav Pandit <parav@mellanox.com>
    Reviewed-by: Mark Bloch <markb@mellanox.com>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bcf38b02d572a72583a4af7325da5f6c6e5a337b
Author: Kloetzke Jan <Jan.Kloetzke@preh.de>
Date:   Tue May 21 13:18:40 2019 +0000

    usbnet: fix kernel crash after disconnect
    
    [ Upstream commit ad70411a978d1e6e97b1e341a7bde9a79af0c93d ]
    
    When disconnecting cdc_ncm the kernel sporadically crashes shortly
    after the disconnect:
    
      [   57.868812] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      ...
      [   58.006653] PC is at 0x0
      [   58.009202] LR is at call_timer_fn+0xec/0x1b4
      [   58.013567] pc : [<0000000000000000>] lr : [<ffffff80080f5130>] pstate: 00000145
      [   58.020976] sp : ffffff8008003da0
      [   58.024295] x29: ffffff8008003da0 x28: 0000000000000001
      [   58.029618] x27: 000000000000000a x26: 0000000000000100
      [   58.034941] x25: 0000000000000000 x24: ffffff8008003e68
      [   58.040263] x23: 0000000000000000 x22: 0000000000000000
      [   58.045587] x21: 0000000000000000 x20: ffffffc68fac1808
      [   58.050910] x19: 0000000000000100 x18: 0000000000000000
      [   58.056232] x17: 0000007f885aff8c x16: 0000007f883a9f10
      [   58.061556] x15: 0000000000000001 x14: 000000000000006e
      [   58.066878] x13: 0000000000000000 x12: 00000000000000ba
      [   58.072201] x11: ffffffc69ff1db30 x10: 0000000000000020
      [   58.077524] x9 : 8000100008001000 x8 : 0000000000000001
      [   58.082847] x7 : 0000000000000800 x6 : ffffff8008003e70
      [   58.088169] x5 : ffffffc69ff17a28 x4 : 00000000ffff138b
      [   58.093492] x3 : 0000000000000000 x2 : 0000000000000000
      [   58.098814] x1 : 0000000000000000 x0 : 0000000000000000
      ...
      [   58.205800] [<          (null)>]           (null)
      [   58.210521] [<ffffff80080f5298>] expire_timers+0xa0/0x14c
      [   58.215937] [<ffffff80080f542c>] run_timer_softirq+0xe8/0x128
      [   58.221702] [<ffffff8008081120>] __do_softirq+0x298/0x348
      [   58.227118] [<ffffff80080a6304>] irq_exit+0x74/0xbc
      [   58.232009] [<ffffff80080e17dc>] __handle_domain_irq+0x78/0xac
      [   58.237857] [<ffffff8008080cf4>] gic_handle_irq+0x80/0xac
      ...
    
    The crash happens roughly 125..130ms after the disconnect. This
    correlates with the 'delay' timer that is started on certain USB tx/rx
    errors in the URB completion handler.
    
    The problem is a race of usbnet_stop() with usbnet_start_xmit(). In
    usbnet_stop() we call usbnet_terminate_urbs() to cancel all URBs in
    flight. This only makes sense if no new URBs are submitted
    concurrently, though. But the usbnet_start_xmit() can run at the same
    time on another CPU which almost unconditionally submits an URB. The
    error callback of the new URB will then schedule the timer after it was
    already stopped.
    
    The fix adds a check if the tx queue is stopped after the tx list lock
    has been taken. This should reliably prevent the submission of new URBs
    while usbnet_terminate_urbs() does its job. The same thing is done on
    the rx side even though it might be safe due to other flags that are
    checked there.
    
    Signed-off-by: Jan Klötzke <Jan.Kloetzke@preh.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8846dd5e7d012bcb32c4708cd31c356d0b706df4
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed May 29 07:44:01 2019 +0200

    r8169: fix MAC address being lost in PCI D3
    
    [ Upstream commit 59715171fbd0172a579576f46821031800a63bc5 ]
    
    (At least) RTL8168e forgets its MAC address in PCI D3. To fix this set
    the MAC address when resuming. For resuming from runtime-suspend we
    had this in place already, for resuming from S3/S5 it was missing.
    
    The commit referenced as being fixed isn't wrong, it's just the first
    one where the patch applies cleanly.
    
    Fixes: 0f07bd850d36 ("r8169: use dev_get_drvdata where possible")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reported-by: Albert Astals Cid <aacid@kde.org>
    Tested-by: Albert Astals Cid <aacid@kde.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6438925b3c4b57bae69507679c83bcaef233dc0a
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Wed May 22 10:05:09 2019 +0000

    net: stmmac: fix reset gpio free missing
    
    [ Upstream commit 49ce881c0d4c4a7a35358d9dccd5f26d0e56fc61 ]
    
    Commit 984203ceff27 ("net: stmmac: mdio: remove reset gpio free")
    removed the reset gpio free, when the driver is unbinded or rmmod,
    we miss the gpio free.
    
    This patch uses managed API to request the reset gpio, so that the
    gpio could be freed properly.
    
    Fixes: 984203ceff27 ("net: stmmac: mdio: remove reset gpio free")
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 22db7d46044d66cedce4a455ea6ca52392450d35
Author: Vlad Buslov <vladbu@mellanox.com>
Date:   Thu May 23 09:32:31 2019 +0300

    net: sched: don't use tc_action->order during action dump
    
    [ Upstream commit 4097e9d250fb17958c1d9b94538386edd3f20144 ]
    
    Function tcf_action_dump() relies on tc_action->order field when starting
    nested nla to send action data to userspace. This approach breaks in
    several cases:
    
    - When multiple filters point to same shared action, tc_action->order field
      is overwritten each time it is attached to filter. This causes filter
      dump to output action with incorrect attribute for all filters that have
      the action in different position (different order) from the last set
      tc_action->order value.
    
    - When action data is displayed using tc action API (RTM_GETACTION), action
      order is overwritten by tca_action_gd() according to its position in
      resulting array of nl attributes, which will break filter dump for all
      filters attached to that shared action that expect it to have different
      order value.
    
    Don't rely on tc_action->order when dumping actions. Set nla according to
    action position in resulting array of actions instead.
    
    Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5386173881a882db603174ba3d58d60f08e11c59
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue May 28 10:34:42 2019 +0100

    net: phy: marvell10g: report if the PHY fails to boot firmware
    
    [ Upstream commit 3d3ced2ec5d71b99d72ae6910fbdf890bc2eccf0 ]
    
    Some boards do not have the PHY firmware programmed in the 3310's flash,
    which leads to the PHY not working as expected.  Warn the user when the
    PHY fails to boot the firmware and refuse to initialise.
    
    Fixes: 20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY support")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1de2974ace0034f7c143c4b6cbd3415521ea5a93
Author: Antoine Tenart <antoine.tenart@bootlin.com>
Date:   Wed May 29 15:59:48 2019 +0200

    net: mvpp2: fix bad MVPP2_TXQ_SCHED_TOKEN_CNTR_REG queue value
    
    [ Upstream commit 21808437214637952b61beaba6034d97880fbeb3 ]
    
    MVPP2_TXQ_SCHED_TOKEN_CNTR_REG() expects the logical queue id but
    the current code is passing the global tx queue offset, so it ends
    up writing to unknown registers (between 0x8280 and 0x82fc, which
    seemed to be unused by the hardware). This fixes the issue by using
    the logical queue id instead.
    
    Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
    Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1efff726b8b32c91843c2cf0689b8677bc1a0290
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Mon May 27 11:04:17 2019 +0000

    net: mvneta: Fix err code path of probe
    
    [ Upstream commit d484e06e25ebb937d841dac02ac1fe76ec7d4ddd ]
    
    Fix below issues in err code path of probe:
    1. we don't need to unregister_netdev() because the netdev isn't
    registered.
    2. when register_netdev() fails, we also need to destroy bm pool for
    HWBM case.
    
    Fixes: dc35a10f68d3 ("net: mvneta: bm: add support for hardware buffer management")
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90bb6fef55bd24d0e85a07f4b1fe0b7ea2df4bd6
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 29 15:36:10 2019 -0700

    net-gro: fix use-after-free read in napi_gro_frags()
    
    [ Upstream commit a4270d6795b0580287453ea55974d948393e66ef ]
    
    If a network driver provides to napi_gro_frags() an
    skb with a page fragment of exactly 14 bytes, the call
    to gro_pull_from_frag0() will 'consume' the fragment
    by calling skb_frag_unref(skb, 0), and the page might
    be freed and reused.
    
    Reading eth->h_proto at the end of napi_frags_skb() might
    read mangled data, or crash under specific debugging features.
    
    BUG: KASAN: use-after-free in napi_frags_skb net/core/dev.c:5833 [inline]
    BUG: KASAN: use-after-free in napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
    Read of size 2 at addr ffff88809366840c by task syz-executor599/8957
    
    CPU: 1 PID: 8957 Comm: syz-executor599 Not tainted 5.2.0-rc1+ #32
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x172/0x1f0 lib/dump_stack.c:113
     print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188
     __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
     kasan_report+0x12/0x20 mm/kasan/common.c:614
     __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
     napi_frags_skb net/core/dev.c:5833 [inline]
     napi_gro_frags+0xc6f/0xd10 net/core/dev.c:5841
     tun_get_user+0x2f3c/0x3ff0 drivers/net/tun.c:1991
     tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2037
     call_write_iter include/linux/fs.h:1872 [inline]
     do_iter_readv_writev+0x5f8/0x8f0 fs/read_write.c:693
     do_iter_write fs/read_write.c:970 [inline]
     do_iter_write+0x184/0x610 fs/read_write.c:951
     vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
     do_writev+0x15b/0x330 fs/read_write.c:1058
    
    Fixes: a50e233c50db ("net-gro: restore frag0 optimization")
    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 10522bcf6d41ba8b365ebcc15719cbe189160587
Author: Andy Duan <fugang.duan@nxp.com>
Date:   Thu May 23 01:55:28 2019 +0000

    net: fec: fix the clk mismatch in failed_reset path
    
    [ Upstream commit ce8d24f9a5965a58c588f9342689702a1024433c ]
    
    Fix the clk mismatch in the error path "failed_reset" because
    below error path will disable clk_ahb and clk_ipg directly, it
    should use pm_runtime_put_noidle() instead of pm_runtime_put()
    to avoid to call runtime resume callback.
    
    Reported-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
    Tested-by: Baruch Siach <baruch@tkos.co.il>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69aa2dc9a9f42e741fc8ce8915071e4883b201c2
Author: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Date:   Wed May 29 07:02:11 2019 +0000

    net: dsa: mv88e6xxx: fix handling of upper half of STATS_TYPE_PORT
    
    [ Upstream commit 84b3fd1fc9592d431e23b077e692fa4e3fd0f086 ]
    
    Currently, the upper half of a 4-byte STATS_TYPE_PORT statistic ends
    up in bits 47:32 of the return value, instead of bits 31:16 as they
    should.
    
    Fixes: 6e46e2d821bb ("net: dsa: mv88e6xxx: Fix u64 statistics")
    Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d07907f584b80803691b91d58c46aa2e5d9d0ef3
Author: Jiri Pirko <jiri@mellanox.com>
Date:   Wed May 29 10:59:44 2019 +0300

    mlxsw: spectrum_acl: Avoid warning after identical rules insertion
    
    [ Upstream commit ef74422020aa8c224b00a927e3e47faac4d8fae3 ]
    
    When identical rules are inserted, the latter one goes to C-TCAM. For
    that, a second eRP with the same mask is created. These 2 eRPs by the
    nature cannot be merged and also one cannot be parent of another.
    Teach mlxsw_sp_acl_erp_delta_fill() about this possibility and handle it
    gracefully.
    
    Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
    Fixes: c22291f7cf45 ("mlxsw: spectrum: acl: Implement delta for ERP")
    Signed-off-by: Jiri Pirko <jiri@mellanox.com>
    Signed-off-by: Ido Schimmel <idosch@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0eb939041b537339bddc0154d010cdfcd645652b
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon May 27 17:35:52 2019 -0700

    llc: fix skb leak in llc_build_and_send_ui_pkt()
    
    [ Upstream commit 8fb44d60d4142cd2a440620cd291d346e23c131e ]
    
    If llc_mac_hdr_init() returns an error, we must drop the skb
    since no llc_build_and_send_ui_pkt() caller will take care of this.
    
    BUG: memory leak
    unreferenced object 0xffff8881202b6800 (size 2048):
      comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.590s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [<00000000e25b5abe>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
        [<00000000e25b5abe>] slab_post_alloc_hook mm/slab.h:439 [inline]
        [<00000000e25b5abe>] slab_alloc mm/slab.c:3326 [inline]
        [<00000000e25b5abe>] __do_kmalloc mm/slab.c:3658 [inline]
        [<00000000e25b5abe>] __kmalloc+0x161/0x2c0 mm/slab.c:3669
        [<00000000a1ae188a>] kmalloc include/linux/slab.h:552 [inline]
        [<00000000a1ae188a>] sk_prot_alloc+0xd6/0x170 net/core/sock.c:1608
        [<00000000ded25bbe>] sk_alloc+0x35/0x2f0 net/core/sock.c:1662
        [<000000002ecae075>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
        [<00000000551f7c47>] llc_ui_create+0x7b/0x140 net/llc/af_llc.c:173
        [<0000000029027f0e>] __sock_create+0x164/0x250 net/socket.c:1430
        [<000000008bdec225>] sock_create net/socket.c:1481 [inline]
        [<000000008bdec225>] __sys_socket+0x69/0x110 net/socket.c:1523
        [<00000000b6439228>] __do_sys_socket net/socket.c:1532 [inline]
        [<00000000b6439228>] __se_sys_socket net/socket.c:1530 [inline]
        [<00000000b6439228>] __x64_sys_socket+0x1e/0x30 net/socket.c:1530
        [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
        [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    BUG: memory leak
    unreferenced object 0xffff88811d750d00 (size 224):
      comm "syz-executor907", pid 7074, jiffies 4294943781 (age 8.600s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 f0 0c 24 81 88 ff ff 00 68 2b 20 81 88 ff ff  ...$.....h+ ....
      backtrace:
        [<0000000053026172>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
        [<0000000053026172>] slab_post_alloc_hook mm/slab.h:439 [inline]
        [<0000000053026172>] slab_alloc_node mm/slab.c:3269 [inline]
        [<0000000053026172>] kmem_cache_alloc_node+0x153/0x2a0 mm/slab.c:3579
        [<00000000fa8f3c30>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:198
        [<00000000d96fdafb>] alloc_skb include/linux/skbuff.h:1058 [inline]
        [<00000000d96fdafb>] alloc_skb_with_frags+0x5f/0x250 net/core/skbuff.c:5327
        [<000000000a34a2e7>] sock_alloc_send_pskb+0x269/0x2a0 net/core/sock.c:2225
        [<00000000ee39999b>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2242
        [<00000000e034d810>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
        [<00000000c0bc8445>] sock_sendmsg_nosec net/socket.c:652 [inline]
        [<00000000c0bc8445>] sock_sendmsg+0x54/0x70 net/socket.c:671
        [<000000003b687167>] __sys_sendto+0x148/0x1f0 net/socket.c:1964
        [<00000000922d78d9>] __do_sys_sendto net/socket.c:1976 [inline]
        [<00000000922d78d9>] __se_sys_sendto net/socket.c:1972 [inline]
        [<00000000922d78d9>] __x64_sys_sendto+0x2a/0x30 net/socket.c:1972
        [<00000000cec820c1>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
        [<000000000c32554f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    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 f57f35f1334796f7c57e2751f7c57539ea560fe9
Author: David Ahern <dsahern@gmail.com>
Date:   Wed May 22 15:12:18 2019 -0700

    ipv6: Fix redirect with VRF
    
    [ Upstream commit 31680ac265802397937d75461a2809a067b9fb93 ]
    
    IPv6 redirect is broken for VRF. __ip6_route_redirect walks the FIB
    entries looking for an exact match on ifindex. With VRF the flowi6_oif
    is updated by l3mdev_update_flow to the l3mdev index and the
    FLOWI_FLAG_SKIP_NH_OIF set in the flags to tell the lookup to skip the
    device match. For redirects the device match is requires so use that
    flag to know when the oif needs to be reset to the skb device index.
    
    Fixes: ca254490c8df ("net: Add VRF support to IPv6 stack")
    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 f2c8b1fc6a8542d9596fb402ee3394076fde78d1
Author: Mike Manning <mmanning@vyatta.att-mail.com>
Date:   Mon May 20 19:57:17 2019 +0100

    ipv6: Consider sk_bound_dev_if when binding a raw socket to an address
    
    [ Upstream commit 72f7cfab6f93a8ea825fab8ccfb016d064269f7f ]
    
    IPv6 does not consider if the socket is bound to a device when binding
    to an address. The result is that a socket can be bound to eth0 and
    then bound to the address of eth1. If the device is a VRF, the result
    is that a socket can only be bound to an address in the default VRF.
    
    Resolve by considering the device if sk_bound_dev_if is set.
    
    Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
    Reviewed-by: David Ahern <dsahern@gmail.com>
    Tested-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 f167aa5a72379e8a87edab24e9ef67d817922dad
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 22 18:35:16 2019 -0700

    ipv4/igmp: fix build error if !CONFIG_IP_MULTICAST
    
    [ Upstream commit 903869bd10e6719b9df6718e785be7ec725df59f ]
    
    ip_sf_list_clear_all() needs to be defined even if !CONFIG_IP_MULTICAST
    
    Fixes: 3580d04aa674 ("ipv4/igmp: fix another memory leak in igmpv3_del_delrec()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: kbuild test robot <lkp@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45bda43ce3a2b071540288dc624eeaa674c06376
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed May 22 16:51:22 2019 -0700

    ipv4/igmp: fix another memory leak in igmpv3_del_delrec()
    
    [ Upstream commit 3580d04aa674383c42de7b635d28e52a1e5bc72c ]
    
    syzbot reported memory leaks [1] that I have back tracked to
    a missing cleanup from igmpv3_del_delrec() when
    (im->sfmode != MCAST_INCLUDE)
    
    Add ip_sf_list_clear_all() and kfree_pmc() helpers to explicitely
    handle the cleanups before freeing.
    
    [1]
    
    BUG: memory leak
    unreferenced object 0xffff888123e32b00 (size 64):
      comm "softirq", pid 0, jiffies 4294942968 (age 8.010s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 e0 00 00 01 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000006105011b>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
        [<000000006105011b>] slab_post_alloc_hook mm/slab.h:439 [inline]
        [<000000006105011b>] slab_alloc mm/slab.c:3326 [inline]
        [<000000006105011b>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
        [<000000004bba8073>] kmalloc include/linux/slab.h:547 [inline]
        [<000000004bba8073>] kzalloc include/linux/slab.h:742 [inline]
        [<000000004bba8073>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
        [<000000004bba8073>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
        [<00000000a46a65a0>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
        [<000000005956ca89>] do_ip_setsockopt.isra.0+0x1795/0x1930 net/ipv4/ip_sockglue.c:957
        [<00000000848e2d2f>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
        [<00000000b9db185c>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
        [<000000003028e438>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
        [<0000000015b65589>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
        [<00000000ac198ef0>] __do_sys_setsockopt net/socket.c:2089 [inline]
        [<00000000ac198ef0>] __se_sys_setsockopt net/socket.c:2086 [inline]
        [<00000000ac198ef0>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
        [<000000000a770437>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
        [<00000000d3adb93b>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Fixes: 9c8bb163ae78 ("igmp, mld: Fix memory leak in igmpv3/mld_del_delrec()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Hangbin Liu <liuhangbin@gmail.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 8d9b786e1124253738e992a845af24d9d95eac68
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Mar 27 12:40:33 2019 -0700

    inet: switch IP ID generator to siphash
    
    [ Upstream commit df453700e8d81b1bdafdf684365ee2b9431fb702 ]
    
    According to Amit Klein and Benny Pinkas, IP ID generation is too weak
    and might be used by attackers.
    
    Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix())
    having 64bit key and Jenkins hash is risky.
    
    It is time to switch to siphash and its 128bit keys.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Reported-by: Benny Pinkas <benny@pinkas.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47f6bf2266fdb115b0e37f1917870698d1255138
Author: Raju Rangoju <rajur@chelsio.com>
Date:   Thu May 23 20:41:44 2019 +0530

    cxgb4: offload VLAN flows regardless of VLAN ethtype
    
    [ Upstream commit b5730061d1056abf317caea823b94d6e12b5b4f6 ]
    
    VLAN flows never get offloaded unless ivlan_vld is set in filter spec.
    It's not compulsory for vlan_ethtype to be set.
    
    So, always enable ivlan_vld bit for offloading VLAN flows regardless of
    vlan_ethtype is set or not.
    
    Fixes: ad9af3e09c (cxgb4: add tc flower match support for vlan)
    Signed-off-by: Raju Rangoju <rajur@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d71c12b91ab8e12709b383dde31dab2fe61993f0
Author: Jarod Wilson <jarod@redhat.com>
Date:   Fri May 24 09:49:28 2019 -0400

    bonding/802.3ad: fix slave link initialization transition states
    
    [ Upstream commit 334031219a84b9994594015aab85ed7754c80176 ]
    
    Once in a while, with just the right timing, 802.3ad slaves will fail to
    properly initialize, winding up in a weird state, with a partner system
    mac address of 00:00:00:00:00:00. This started happening after a fix to
    properly track link_failure_count tracking, where an 802.3ad slave that
    reported itself as link up in the miimon code, but wasn't able to get a
    valid speed/duplex, started getting set to BOND_LINK_FAIL instead of
    BOND_LINK_DOWN. That was the proper thing to do for the general "my link
    went down" case, but has created a link initialization race that can put
    the interface in this odd state.
    
    The simple fix is to instead set the slave link to BOND_LINK_DOWN again,
    if the link has never been up (last_link_up == 0), so the link state
    doesn't bounce from BOND_LINK_DOWN to BOND_LINK_FAIL -- it hasn't failed
    in this case, it simply hasn't been up yet, and this prevents the
    unnecessary state change from DOWN to FAIL and getting stuck in an init
    failure w/o a partner mac.
    
    Fixes: ea53abfab960 ("bonding/802.3ad: fix link_failure_count tracking")
    CC: Jay Vosburgh <j.vosburgh@gmail.com>
    CC: Veaceslav Falico <vfalico@gmail.com>
    CC: Andy Gospodarek <andy@greyhouse.net>
    CC: "David S. Miller" <davem@davemloft.net>
    CC: netdev@vger.kernel.org
    Tested-by: Heesoon Kim <Heesoon.Kim@stratus.com>
    Signed-off-by: Jarod Wilson <jarod@redhat.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>