commit a7eb81c1d11ae311c25db88c25a7d5228fe5680a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Apr 21 12:56:18 2021 +0200

    Linux 5.4.114
    
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Link: https://lore.kernel.org/r/20210419130523.802169214@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3822683fd10108083de6af19c185d700109c3fbd
Author: Pali Rohár <pali@kernel.org>
Date:   Mon Apr 12 18:57:39 2021 +0200

    net: phy: marvell: fix detection of PHY on Topaz switches
    
    commit 1fe976d308acb6374c899a4ee8025a0a016e453e upstream.
    
    Since commit fee2d546414d ("net: phy: marvell: mv88e6390 temperature
    sensor reading"), Linux reports the temperature of Topaz hwmon as
    constant -75°C.
    
    This is because switches from the Topaz family (88E6141 / 88E6341) have
    the address of the temperature sensor register different from Peridot.
    
    This address is instead compatible with 88E1510 PHYs, as was used for
    Topaz before the above mentioned commit.
    
    Create a new mapping table between switch family and PHY ID for families
    which don't have a model number. And define PHY IDs for Topaz and Peridot
    families.
    
    Create a new PHY ID and a new PHY driver for Topaz's internal PHY.
    The only difference from Peridot's PHY driver is the HWMON probing
    method.
    
    Prior this change Topaz's internal PHY is detected by kernel as:
    
      PHY [...] driver [Marvell 88E6390] (irq=63)
    
    And afterwards as:
    
      PHY [...] driver [Marvell 88E6341 Family] (irq=63)
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    BugLink: https://github.com/globalscaletechnologies/linux/issues/1
    Fixes: fee2d546414d ("net: phy: marvell: mv88e6390 temperature sensor reading")
    Reviewed-by: Marek Behún <kabel@kernel.org>
    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 cec3b778f70fbd02f07beddabcf8932884502c09
Author: Fredrik Strupe <fredrik@strupe.net>
Date:   Mon Apr 5 21:52:05 2021 +0100

    ARM: 9071/1: uprobes: Don't hook on thumb instructions
    
    commit d2f7eca60b29006285d57c7035539e33300e89e5 upstream.
    
    Since uprobes is not supported for thumb, check that the thumb bit is
    not set when matching the uprobes instruction hooks.
    
    The Arm UDF instructions used for uprobes triggering
    (UPROBE_SWBP_ARM_INSN and UPROBE_SS_ARM_INSN) coincidentally share the
    same encoding as a pair of unallocated 32-bit thumb instructions (not
    UDF) when the condition code is 0b1111 (0xf). This in effect makes it
    possible to trigger the uprobes functionality from thumb, and at that
    using two unallocated instructions which are not permanently undefined.
    
    Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
    Cc: stable@vger.kernel.org
    Fixes: c7edc9e326d5 ("ARM: add uprobes support")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f0cda5e9e62b9c6e9ff6c5d7beff03732c652f6
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Apr 14 10:47:10 2021 +0200

    r8169: don't advertise pause in jumbo mode
    
    [ Upstream commit 453a77894efa4d9b6ef9644d74b9419c47ac427c ]
    
    It has been reported [0] that using pause frames in jumbo mode impacts
    performance. There's no available chip documentation, but vendor
    drivers r8168 and r8125 don't advertise pause in jumbo mode. So let's
    do the same, according to Roman it fixes the issue.
    
    [0] https://bugzilla.kernel.org/show_bug.cgi?id=212617
    
    Fixes: 9cf9b84cc701 ("r8169: make use of phy_set_asym_pause")
    Reported-by: Roman Mamedov <rm+bko@romanrm.net>
    Tested-by: Roman Mamedov <rm+bko@romanrm.net>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c5934da725bb53c21ef7d99e83b418f61fb7e4bb
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Jan 9 23:01:18 2021 +0100

    r8169: tweak max read request size for newer chips also in jumbo mtu mode
    
    [ Upstream commit 5e00e16cb98935bcf06f51931876d898c226f65c ]
    
    So far we don't increase the max read request size if we switch to
    jumbo mode before bringing up the interface for the first time.
    Let's change this.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50b7a68664dc7f65be55c9ec45d7ed2c8995c252
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Feb 15 14:52:58 2020 +0100

    r8169: improve rtl_jumbo_config
    
    [ Upstream commit 9db0ac57bd3286fedcf43a86b29b847cea281cc7 ]
    
    Merge enabling and disabling jumbo packets to one function to make
    the code a little simpler.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cbbd3e2a2e7c695e134ac2ece6080da79b4687cd
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Feb 5 21:22:46 2020 +0100

    r8169: fix performance regression related to PCIe max read request size
    
    [ Upstream commit 21b5f672fb2eb1366dedc4ac9d32431146b378d3 ]
    
    It turned out that on low performance systems the original change can
    cause lower tx performance. On a N3450-based mini-PC tx performance
    in iperf3 was reduced from 950Mbps to ~900Mbps. Therefore effectively
    revert the original change, just use pcie_set_readrq() now instead of
    changing the PCIe capability register directly.
    
    Fixes: 2df49d365498 ("r8169: remove fiddling with the PCIe max read request size")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0243bb3941862a22767973c8410c320e03ab12c7
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Oct 21 21:22:42 2019 +0200

    r8169: simplify setting PCI_EXP_DEVCTL_NOSNOOP_EN
    
    [ Upstream commit e0bbe7cbb3c5ff72d680993edf89db2391e80d5d ]
    
    r8168b_0_hw_jumbo_enable() and r8168b_0_hw_jumbo_disable() both do the
    same and just set PCI_EXP_DEVCTL_NOSNOOP_EN. We can simplify the code
    by moving this setting for RTL8168B to rtl_hw_start_8168().
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c667953d64338c07ae9f4386c06b4c56eaf27d09
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Oct 21 21:22:07 2019 +0200

    r8169: remove fiddling with the PCIe max read request size
    
    [ Upstream commit 2df49d36549808a7357ad9f78b7a8e39516e7809 ]
    
    The attempt to improve performance by changing the PCIe max read request
    size was added in the vendor driver more than 10 years back and copied
    to r8169 driver. In the vendor driver this has been removed long ago.
    Obviously it had no effect, also in my tests I didn't see any
    difference. Typically the max payload size is less than 512 bytes
    anyway, and the PCI core takes care that the maximum supported value
    is set. So let's remove fiddling with PCIe max read request size from
    r8169 too.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b14992c962747e0608e087027db4ebf745ebfcd2
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Tue Mar 16 14:42:19 2021 +0000

    arm64: dts: allwinner: Fix SD card CD GPIO for SOPine systems
    
    [ Upstream commit 3dd4ce4185df6798dcdcc3669bddb35899d7d5e1 ]
    
    Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from
    SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
    along the way with the Pine64-LTS, which share the same base .dtsi.
    
    However while both boards indeed have a working CD GPIO on PF6, the
    polarity is different: the SOPine modules uses a "push-pull" socket,
    which has an active-high switch, while the Pine64-LTS use the more
    traditional push-push socket and the common active-low switch.
    
    Fix the polarity in the sopine.dtsi, and overwrite it in the LTS
    board .dts, to make the SD card work again on systems using SOPine
    modules.
    
    Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
    Reported-by: Ashley <contact@victorianfox.com>
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20210316144219.5973-1-andre.przywara@arm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 871b569a3e67f570df9f5ba195444dc7c621293b
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Thu Mar 25 10:26:21 2021 +0000

    ARM: footbridge: fix PCI interrupt mapping
    
    [ Upstream commit 30e3b4f256b4e366a61658c294f6a21b8626dda7 ]
    
    Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
    pci_device_probe()"), the PCI code will call the IRQ mapping function
    whenever a PCI driver is probed. If these are marked as __init, this
    causes an oops if a PCI driver is loaded or bound after the kernel has
    initialised.
    
    Fixes: 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in pci_device_probe()")
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a7ac9afc8d77e3bd99583164fa3bc8b9e6b4a48
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Apr 13 05:41:35 2021 -0700

    gro: ensure frag0 meets IP header alignment
    
    commit 38ec4944b593fd90c5ef42aaaa53e66ae5769d04 upstream.
    
    After commit 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
    Guenter Roeck reported one failure in his tests using sh architecture.
    
    After much debugging, we have been able to spot silent unaligned accesses
    in inet_gro_receive()
    
    The issue at hand is that upper networking stacks assume their header
    is word-aligned. Low level drivers are supposed to reserve NET_IP_ALIGN
    bytes before the Ethernet header to make that happen.
    
    This patch hardens skb_gro_reset_offset() to not allow frag0 fast-path
    if the fragment is not properly aligned.
    
    Some arches like x86, arm64 and powerpc do not care and define NET_IP_ALIGN
    as 0, this extra check will be a NOP for them.
    
    Note that if frag0 is not used, GRO will call pskb_may_pull()
    as many times as needed to pull network and transport headers.
    
    Fixes: 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head")
    Fixes: 78a478d0efd9 ("gro: Inline skb_gro_header and cache frag0 virtual address")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fde195c03bff160b90e6a21c2fd7159b685846a9
Author: Lijun Pan <lijunp213@gmail.com>
Date:   Wed Apr 14 02:46:16 2021 -0500

    ibmvnic: remove duplicate napi_schedule call in open function
    
    commit 7c451f3ef676c805a4b77a743a01a5c21a250a73 upstream.
    
    Remove the unnecessary napi_schedule() call in __ibmvnic_open() since
    interrupt_rx() calls napi_schedule_prep/__napi_schedule during every
    receive interrupt.
    
    Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
    Signed-off-by: Lijun Pan <lijunp213@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c591bbaae545b507681819e99637c1e5eb3ada73
Author: Lijun Pan <lijunp213@gmail.com>
Date:   Wed Apr 14 02:46:15 2021 -0500

    ibmvnic: remove duplicate napi_schedule call in do_reset function
    
    commit d3a6abccbd272aea7dc2c6f984bb5a2c11278e44 upstream.
    
    During adapter reset, do_reset/do_hard_reset calls ibmvnic_open(),
    which will calls napi_schedule if previous state is VNIC_CLOSED
    (i.e, the reset case, and "ifconfig down" case). So there is no need
    for do_reset to call napi_schedule again at the end of the function
    though napi_schedule will neglect the request if napi is already
    scheduled.
    
    Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
    Signed-off-by: Lijun Pan <lijunp213@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6acd7d19124c5c8dc765079d19024ea47f21fbd
Author: Lijun Pan <lijunp213@gmail.com>
Date:   Wed Apr 14 02:46:14 2021 -0500

    ibmvnic: avoid calling napi_disable() twice
    
    commit 0775ebc4cf8554bdcd2c212669a0868ab68df5c0 upstream.
    
    __ibmvnic_open calls napi_disable without checking whether NAPI polling
    has already been disabled or not. This could cause napi_disable
    being called twice, which could generate deadlock. For example,
    the first napi_disable will spin until NAPI_STATE_SCHED is cleared
    by napi_complete_done, then set it again.
    When napi_disable is called the second time, it will loop infinitely
    because no dev->poll will be running to clear NAPI_STATE_SCHED.
    
    To prevent above scenario from happening, call ibmvnic_napi_disable()
    which checks if napi is disabled or not before calling napi_disable.
    
    Fixes: bfc32f297337 ("ibmvnic: Move resource initialization to its own routine")
    Suggested-by: Thomas Falcon <tlfalcon@linux.ibm.com>
    Signed-off-by: Lijun Pan <lijunp213@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2bc14f5eca106247fa3761b9a17714973b30381f
Author: Jason Xing <xingwanli@kuaishou.com>
Date:   Wed Apr 14 10:34:28 2021 +0800

    i40e: fix the panic when running bpf in xdpdrv mode
    
    commit 4e39a072a6a0fc422ba7da5e4336bdc295d70211 upstream.
    
    Fix this panic by adding more rules to calculate the value of @rss_size_max
    which could be used in allocating the queues when bpf is loaded, which,
    however, could cause the failure and then trigger the NULL pointer of
    vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
    cpus are online and then allocates 256 queues on the machine with 32 cpus
    online actually.
    
    Once the load of bpf begins, the log will go like this "failed to get
    tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
    failed".
    
    Thus, I attach the key information of the crash-log here.
    
    BUG: unable to handle kernel NULL pointer dereference at
    0000000000000000
    RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
    Call Trace:
    [2160294.717292]  ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
    [2160294.717666]  dev_xdp_install+0x4f/0x70
    [2160294.718036]  dev_change_xdp_fd+0x11f/0x230
    [2160294.718380]  ? dev_disable_lro+0xe0/0xe0
    [2160294.718705]  do_setlink+0xac7/0xe70
    [2160294.719035]  ? __nla_parse+0xed/0x120
    [2160294.719365]  rtnl_newlink+0x73b/0x860
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Co-developed-by: Shujin Li <lishujin@kuaishou.com>
    Signed-off-by: Shujin Li <lishujin@kuaishou.com>
    Signed-off-by: Jason Xing <xingwanli@kuaishou.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 51edda8a6334d816af9621c6c2b22a34dfdf4d6b
Author: Hristo Venev <hristo@venev.name>
Date:   Mon Apr 12 20:41:17 2021 +0300

    net: ip6_tunnel: Unregister catch-all devices
    
    commit 941ea91e87a6e879ed82dad4949f6234f2702bec upstream.
    
    Similarly to the sit case, we need to remove the tunnels with no
    addresses that have been moved to another network namespace.
    
    Fixes: 0bd8762824e73 ("ip6tnl: add x-netns support")
    Signed-off-by: Hristo Venev <hristo@venev.name>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92f93a03cef090fb2cd9ac3d5a1f4d07f59c6980
Author: Hristo Venev <hristo@venev.name>
Date:   Mon Apr 12 20:41:16 2021 +0300

    net: sit: Unregister catch-all devices
    
    commit 610f8c0fc8d46e0933955ce13af3d64484a4630a upstream.
    
    A sit interface created without a local or a remote address is linked
    into the `sit_net::tunnels_wc` list of its original namespace. When
    deleting a network namespace, delete the devices that have been moved.
    
    The following script triggers a null pointer dereference if devices
    linked in a deleted `sit_net` remain:
    
        for i in `seq 1 30`; do
            ip netns add ns-test
            ip netns exec ns-test ip link add dev veth0 type veth peer veth1
            ip netns exec ns-test ip link add dev sit$i type sit dev veth0
            ip netns exec ns-test ip link set dev sit$i netns $$
            ip netns del ns-test
        done
        for i in `seq 1 30`; do
            ip link del dev sit$i
        done
    
    Fixes: 5e6700b3bf98f ("sit: add support of x-netns")
    Signed-off-by: Hristo Venev <hristo@venev.name>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4fcbb1fa2703a000cdd608c403e7af6423e12f97
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Apr 11 11:02:08 2021 +0200

    net: davicom: Fix regulator not turned off on failed probe
    
    commit 31457db3750c0b0ed229d836f2609fdb8a5b790e upstream.
    
    When the probe fails, we must disable the regulator that was previously
    enabled.
    
    This patch is a follow-up to commit ac88c531a5b3
    ("net: davicom: Fix regulator not turned off on failed probe") which missed
    one case.
    
    Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
    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 01fb1626b620cb37a65ad08e0f626489e8f042ef
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Apr 9 08:49:39 2021 -0700

    netfilter: nft_limit: avoid possible divide error in nft_limit_init
    
    commit b895bdf5d643b6feb7c60856326dd4feb6981560 upstream.
    
    div_u64() divides u64 by u32.
    
    nft_limit_init() wants to divide u64 by u64, use the appropriate
    math function (div64_u64)
    
    divide error: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]
    RIP: 0010:div_u64 include/linux/math64.h:127 [inline]
    RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85
    Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00
    RSP: 0018:ffffc90009447198 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003
    RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000
    R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    FS:  000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]
     nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713
     nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160
     nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321
     nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456
     nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline]
     nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598
     netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
     netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
     sock_sendmsg_nosec net/socket.c:654 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:674
     ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
     __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: c26844eda9d4 ("netfilter: nf_tables: Fix nft limit burst handling")
    Fixes: 3e0f64b7dd31 ("netfilter: nft_limit: fix packet ratelimiting")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Diagnosed-by: Luigi Rizzo <lrizzo@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e65cd80558e5a87f4d9d4e6ac660e6aa9ea222ff
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Wed Apr 14 14:20:29 2021 +0300

    net: macb: fix the restore of cmp registers
    
    commit a714e27ea8bdee2b238748029d31472d0a65b611 upstream.
    
    Commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
    introduces the restore of CMP registers on resume path. In case the IP
    doesn't support type 2 screeners (zero on DCFG8 register) the
    struct macb::rx_fs_list::list is not initialized and thus the
    list_for_each_entry(item, &bp->rx_fs_list.list, list) loop introduced in
    commit a14d273ba159 ("net: macb: restore cmp registers on resume path")
    will access an uninitialized list leading to crash. Thus, initialize
    the struct macb::rx_fs_list::list without taking into account if the
    IP supports type 2 screeners or not.
    
    Fixes: a14d273ba159 ("net: macb: restore cmp registers on resume path")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6449b405f99accf3674d34a88d6f3dad6c87a150
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Apr 7 21:43:40 2021 +0200

    netfilter: arp_tables: add pre_exit hook for table unregister
    
    commit d163a925ebbc6eb5b562b0f1d72c7e817aa75c40 upstream.
    
    Same problem that also existed in iptables/ip(6)tables, when
    arptable_filter is removed there is no longer a wait period before the
    table/ruleset is free'd.
    
    Unregister the hook in pre_exit, then remove the table in the exit
    function.
    This used to work correctly because the old nf_hook_unregister API
    did unconditional synchronize_net.
    
    The per-net hook unregister function uses call_rcu instead.
    
    Fixes: b9e69e127397 ("netfilter: xtables: don't hook tables by default")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce23be37ecac4b1025ede0dca91406e83157cb6d
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Apr 7 21:43:39 2021 +0200

    netfilter: bridge: add pre_exit hooks for ebtable unregistration
    
    commit 7ee3c61dcd28bf6e290e06ad382f13511dc790e9 upstream.
    
    Just like ip/ip6/arptables, the hooks have to be removed, then
    synchronize_rcu() has to be called to make sure no more packets are being
    processed before the ruleset data is released.
    
    Place the hook unregistration in the pre_exit hook, then call the new
    ebtables pre_exit function from there.
    
    Years ago, when first netns support got added for netfilter+ebtables,
    this used an older (now removed) netfilter hook unregister API, that did
    a unconditional synchronize_rcu().
    
    Now that all is done with call_rcu, ebtable_{filter,nat,broute} pernet exit
    handlers may free the ebtable ruleset while packets are still in flight.
    
    This can only happens on module removal, not during netns exit.
    
    The new function expects the table name, not the table struct.
    
    This is because upcoming patch set (targeting -next) will remove all
    net->xt.{nat,filter,broute}_table instances, this makes it necessary
    to avoid external references to those member variables.
    
    The existing APIs will be converted, so follow the upcoming scheme of
    passing name + hook type instead.
    
    Fixes: aee12a0a3727e ("ebtables: remove nf_hook_register usage")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61ca5b653220bb644e1623c424487318bbdfbac9
Author: Vaibhav Jain <vaibhav@linux.ibm.com>
Date:   Fri Apr 2 14:55:55 2021 +0530

    libnvdimm/region: Fix nvdimm_has_flush() to handle ND_REGION_ASYNC
    
    commit a2948b17f6b936fc52f86c0f92c46d2f91928b79 upstream.
    
    In case a platform doesn't provide explicit flush-hints but provides an
    explicit flush callback via ND_REGION_ASYNC region flag, then
    nvdimm_has_flush() still returns '0' indicating that writes do not
    require flushing. This happens on PPC64 with patch at [1] applied, where
    'deep_flush' of a region was denied even though an explicit flush
    function was provided.
    
    Fix this by adding a condition to nvdimm_has_flush() to test for the
    ND_REGION_ASYNC flag on the region and see if a 'region->flush' callback
    is assigned.
    
    Link: http://lore.kernel.org/r/161703936121.36.7260632399582101498.stgit@e1fbed493c87 [1]
    Fixes: c5d4355d10d4 ("libnvdimm: nd_region flush callback support")
    Reported-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
    Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210402092555.208590-1-vaibhav@linux.ibm.com
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ce8e86d125dd6944abcd2f3d92200ad1340df38
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Wed Mar 31 01:04:45 2021 +0200

    netfilter: conntrack: do not print icmpv6 as unknown via /proc
    
    commit fbea31808ca124dd73ff6bb1e67c9af4607c3e32 upstream.
    
    /proc/net/nf_conntrack shows icmpv6 as unknown.
    
    Fixes: 09ec82f5af99 ("netfilter: conntrack: remove protocol name from l4proto struct")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f6c1a81713e082ac6a8c03c9ca58891c8ac85b8
Author: Jolly Shah <jollys@google.com>
Date:   Thu Mar 18 15:56:32 2021 -0700

    scsi: libsas: Reset num_scatter if libata marks qc as NODATA
    
    commit 176ddd89171ddcf661862d90c5d257877f7326d6 upstream.
    
    When the cache_type for the SCSI device is changed, the SCSI layer issues a
    MODE_SELECT command. The caching mode details are communicated via a
    request buffer associated with the SCSI command with data direction set as
    DMA_TO_DEVICE (scsi_mode_select()). When this command reaches the libata
    layer, as a part of generic initial setup, libata layer sets up the
    scatterlist for the command using the SCSI command (ata_scsi_qc_new()).
    This command is then translated by the libata layer into
    ATA_CMD_SET_FEATURES (ata_scsi_mode_select_xlat()). The libata layer treats
    this as a non-data command (ata_mselect_caching()), since it only needs an
    ATA taskfile to pass the caching on/off information to the device. It does
    not need the scatterlist that has been setup, so it does not perform
    dma_map_sg() on the scatterlist (ata_qc_issue()). Unfortunately, when this
    command reaches the libsas layer (sas_ata_qc_issue()), libsas layer sees it
    as a non-data command with a scatterlist. It cannot extract the correct DMA
    length since the scatterlist has not been mapped with dma_map_sg() for a
    DMA operation. When this partially constructed SAS task reaches pm80xx
    LLDD, it results in the following warning:
    
    "pm80xx_chip_sata_req 6058: The sg list address
    start_addr=0x0000000000000000 data_len=0x0end_addr_high=0xffffffff
    end_addr_low=0xffffffff has crossed 4G boundary"
    
    Update libsas to handle ATA non-data commands separately so num_scatter and
    total_xfer_len remain 0.
    
    Link: https://lore.kernel.org/r/20210318225632.2481291-1-jollys@google.com
    Fixes: 53de092f47ff ("scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA")
    Tested-by: Luo Jiaxing <luojiaxing@huawei.com>
    Reviewed-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Jolly Shah <jollys@google.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7779f84e4677da74cfc516f52144f6f9c46e8d7a
Author: Kefeng Wang <wangkefeng.wang@huawei.com>
Date:   Mon Mar 29 11:13:07 2021 +0800

    riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"
    
    commit 199fc6b8dee7d6d50467a57e0dc7e3e1b7d59966 upstream.
    
    There is a spelling mistake when SPARSEMEM Kconfig copy.
    
    Fixes: a5406a7ff56e ("riscv: Correct SPARSEMEM configuration")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
    Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec3bb712fb62965c0f3983bfa0c859fbf4a6f955
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Mon Apr 12 23:41:24 2021 +0200

    vfio/pci: Add missing range check in vfio_pci_mmap
    
    commit 909290786ea335366e21d7f1ed5812b90f2f0a92 upstream.
    
    When mmaping an extra device region verify that the region index
    derived from the mmap offset is valid.
    
    Fixes: a15b1883fee1 ("vfio_pci: Allow mapping extra regions")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Message-Id: <20210412214124.GA241759@lisa.in-ulm.de>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Reviewed-by: Cornelia Huck <cohuck@redhat.com>
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9e8c5e3d827906d8c2f9f914a508ffe6403c10dc
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Apr 13 17:08:04 2021 -0700

    arm64: alternatives: Move length validation in alternative_{insn, endif}
    
    commit 22315a2296f4c251fa92aec45fbbae37e9301b6c upstream.
    
    After commit 2decad92f473 ("arm64: mte: Ensure TIF_MTE_ASYNC_FAULT is
    set atomically"), LLVM's integrated assembler fails to build entry.S:
    
    <instantiation>:5:7: error: expected assembly-time absolute expression
     .org . - (664b-663b) + (662b-661b)
          ^
    <instantiation>:6:7: error: expected assembly-time absolute expression
     .org . - (662b-661b) + (664b-663b)
          ^
    
    The root cause is LLVM's assembler has a one-pass design, meaning it
    cannot figure out these instruction lengths when the .org directive is
    outside of the subsection that they are in, which was changed by the
    .arch_extension directive added in the above commit.
    
    Apply the same fix from commit 966a0acce2fc ("arm64/alternatives: move
    length validation inside the subsection") to the alternative_endif
    macro, shuffling the .org directives so that the length validation
    happen will always happen in the same subsections. alternative_insn has
    not shown any issue yet but it appears that it could have the same issue
    in the future so just preemptively change it.
    
    Fixes: f7b93d42945c ("arm64/alternatives: use subsections for replacement sequences")
    Cc: <stable@vger.kernel.org> # 5.8.x
    Link: https://github.com/ClangBuiltLinux/linux/issues/1347
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Tested-by: Sami Tolvanen <samitolvanen@google.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Nick Desaulniers <ndesaulniers@google.com>
    Link: https://lore.kernel.org/r/20210414000803.662534-1-nathan@kernel.org
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b7d15166c1d147b8bf84295bb55ce0d91eb16ad2
Author: Peter Collingbourne <pcc@google.com>
Date:   Thu Apr 1 09:51:10 2021 -0700

    arm64: fix inline asm in load_unaligned_zeropad()
    
    commit 185f2e5f51c2029efd9dd26cceb968a44fe053c6 upstream.
    
    The inline asm's addr operand is marked as input-only, however in
    the case where an exception is taken it may be modified by the BIC
    instruction on the exception path. Fix the problem by using a temporary
    register as the destination register for the BIC instruction.
    
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Cc: stable@vger.kernel.org
    Link: https://linux-review.googlesource.com/id/I84538c8a2307d567b4f45bb20b715451005f9617
    Link: https://lore.kernel.org/r/20210401165110.3952103-1-pcc@google.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9956950f23ce4dabe9164d8080791035616db6f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Apr 17 09:27:04 2021 -0700

    readdir: make sure to verify directory entry for legacy interfaces too
    
    commit 0c93ac69407d63a85be0129aa55ffaec27ffebd3 upstream.
    
    This does the directory entry name verification for the legacy
    "fillonedir" (and compat) interface that goes all the way back to the
    dark ages before we had a proper dirent, and the readdir() system call
    returned just a single entry at a time.
    
    Nobody should use this interface unless you still have binaries from
    1991, but let's do it right.
    
    This came up during discussions about unsafe_copy_to_user() and proper
    checking of all the inputs to it, as the networking layer is looking to
    use it in a few new places.  So let's make sure the _old_ users do it
    all right and proper, before we add new ones.
    
    See also commit 8a23eb804ca4 ("Make filldir[64]() verify the directory
    entry filename is valid") which did the proper modern interfaces that
    people actually use. It had a note:
    
        Note that I didn't bother adding the checks to any legacy interfaces
        that nobody uses.
    
    which this now corrects.  Note that we really don't care about POSIX and
    the presense of '/' in a directory entry, but verify_dirent_name() also
    ends up doing the proper name length verification which is what the
    input checking discussion was about.
    
    [ Another option would be to remove the support for this particular very
      old interface: any binaries that use it are likely a.out binaries, and
      they will no longer run anyway since we removed a.out binftm support
      in commit eac616557050 ("x86: Deprecate a.out support").
    
      But I'm not sure which came first: getdents() or ELF support, so let's
      pretend somebody might still have a working binary that uses the
      legacy readdir() case.. ]
    
    Link: https://lore.kernel.org/lkml/CAHk-=wjbvzCAhAtvG0d81W5o0-KT5PPTHhfJ5ieDFq+bGtgOYg@mail.gmail.com/
    Acked-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ff821c7ce913c4c0516a5b38abb9c123c17e684f
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date:   Wed Apr 14 08:28:28 2021 -0700

    dm verity fec: fix misaligned RS roots IO
    
    commit 8ca7cab82bda4eb0b8064befeeeaa38106cac637 upstream.
    
    commit df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to
    block size") introduced the possibility for misaligned roots IO
    relative to the underlying device's logical block size. E.g. Android's
    default RS roots=2 results in dm_bufio->block_size=1024, which causes
    the following EIO if the logical block size of the device is 4096,
    given v->data_dev_block_bits=12:
    
    E sd 0    : 0:0:0: [sda] tag#30 request not aligned to the logical block size
    E blk_update_request: I/O error, dev sda, sector 10368424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
    E device-mapper: verity-fec: 254:8: FEC 9244672: parity read failed (block 18056): -5
    
    Fix this by onlu using f->roots for dm_bufio blocksize IFF it is
    aligned to v->data_dev_block_bits.
    
    Fixes: df7b59ba9245 ("dm verity: fix FEC for RS roots unaligned to block size")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 804607635cc1a4286422e298c4895fec79f01788
Author: Ping Cheng <pinglinux@gmail.com>
Date:   Thu Mar 11 11:30:09 2021 -0800

    HID: wacom: set EV_KEY and EV_ABS only for non-HID_GENERIC type of devices
    
    commit 276559d8d02c2709281578976ca2f53bc62063d4 upstream.
    
    Valid HID_GENERIC type of devices set EV_KEY and EV_ABS by wacom_map_usage.
    When *_input_capabilities are reached, those devices should already have
    their proper EV_* set. EV_KEY and EV_ABS only need to be set for
    non-HID_GENERIC type of devices in *_input_capabilities.
    
    Devices that don't support HID descitoprs will pass back to hid-input for
    registration without being accidentally rejected by the introduction of
    patch: "Input: refuse to register absolute devices without absinfo"
    
    Fixes: 6ecfe51b4082 ("Input: refuse to register absolute devices without absinfo")
    Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
    Reviewed-by: Jason Gerecke <Jason.Gerecke@wacom.com>
    Tested-by: Juan Garrido <Juan.Garrido@wacom.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b428063fb31089806bfa4d93e70f67da204982cc
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 23 09:56:34 2021 -0700

    Input: i8042 - fix Pegatron C15B ID entry
    
    commit daa58c8eec0a65ac8e2e77ff3ea8a233d8eec954 upstream.
    
    The Zenbook Flip entry that was added overwrites a previous one
    because of a typo:
    
    In file included from drivers/input/serio/i8042.h:23,
                     from drivers/input/serio/i8042.c:131:
    drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field overwritten [-Werror=override-init]
      591 |                 .matches = {
          |                            ^
    drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for 'i8042_dmi_noselftest_table[0].matches')
    
    Add the missing separator between the two.
    
    Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Marcos Paulo de Souza <mpdesouza@suse.com>
    Link: https://lore.kernel.org/r/20210323130623.2302402-1-arnd@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 995503dd6546ba2c33fb1e0aba43a56b83c2de35
Author: Caleb Connolly <caleb@connolly.tech>
Date:   Sun Mar 7 15:12:22 2021 -0800

    Input: s6sy761 - fix coordinate read bit shift
    
    commit 30b3f68715595dee7fe4d9bd91a2252c3becdf0a upstream.
    
    The touch coordinate register contains the following:
    
            byte 3             byte 2             byte 1
    +--------+--------+ +-----------------+ +-----------------+
    |        |        | |                 | |                 |
    | X[3:0] | Y[3:0] | |     Y[11:4]     | |     X[11:4]     |
    |        |        | |                 | |                 |
    +--------+--------+ +-----------------+ +-----------------+
    
    Bytes 2 and 1 need to be shifted left by 4 bits, the least significant
    nibble of each is stored in byte 3. Currently they are only
    being shifted by 3 causing the reported coordinates to be incorrect.
    
    This matches downstream examples, and has been confirmed on my
    device (OnePlus 7 Pro).
    
    Fixes: 0145a7141e59 ("Input: add support for the Samsung S6SY761 touchscreen")
    Signed-off-by: Caleb Connolly <caleb@connolly.tech>
    Reviewed-by: Andi Shyti <andi@etezian.org>
    Link: https://lore.kernel.org/r/20210305185710.225168-1-caleb@connolly.tech
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a2ac9ed8cf6d078a73387716b0a19b6e03fd7dc
Author: A. Cody Schuffelen <schuffelen@google.com>
Date:   Thu Mar 18 13:04:19 2021 -0700

    virt_wifi: Return micros for BSS TSF values
    
    [ Upstream commit b57aa17f07c9270e576ef7df09f142978b5a75f0 ]
    
    cfg80211_inform_bss expects to receive a TSF value, but is given the
    time since boot in nanoseconds. TSF values are expected to be at
    microsecond scale rather than nanosecond scale.
    
    Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
    Link: https://lore.kernel.org/r/20210318200419.1421034-1-schuffelen@google.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd7e90c82850f49c23004d54de14e46d373748a6
Author: Seevalamuthu Mariappan <seevalam@codeaurora.org>
Date:   Fri Mar 19 19:48:52 2021 +0530

    mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN
    
    [ Upstream commit dd0b45538146cb6a54d6da7663b8c3afd16ebcfd ]
    
    In some race conditions, with more clients and traffic configuration,
    below crash is seen when making the interface down. sta->fast_rx wasn't
    cleared when STA gets removed from 4-addr AP_VLAN interface. The crash is
    due to try accessing 4-addr AP_VLAN interface's net_device (fast_rx->dev)
    which has been deleted already.
    
    Resolve this by clearing sta->fast_rx pointer when STA removes
    from a 4-addr VLAN.
    
    [  239.449529] Unable to handle kernel NULL pointer dereference at virtual address 00000004
    [  239.449531] pgd = 80204000
    ...
    [  239.481496] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.60 #227
    [  239.481591] Hardware name: Generic DT based system
    [  239.487665] task: be05b700 ti: be08e000 task.ti: be08e000
    [  239.492360] PC is at get_rps_cpu+0x2d4/0x31c
    [  239.497823] LR is at 0xbe08fc54
    ...
    [  239.778574] [<80739740>] (get_rps_cpu) from [<8073cb10>] (netif_receive_skb_internal+0x8c/0xac)
    [  239.786722] [<8073cb10>] (netif_receive_skb_internal) from [<8073d578>] (napi_gro_receive+0x48/0xc4)
    [  239.795267] [<8073d578>] (napi_gro_receive) from [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames+0xbcc/0x12d4 [mac80211])
    [  239.804776] [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames [mac80211]) from [<c7b84d4c>] (ieee80211_rx_napi+0x7b8/0x8c8 [mac8
                0211])
    [  239.815857] [<c7b84d4c>] (ieee80211_rx_napi [mac80211]) from [<c7f63d7c>] (ath11k_dp_process_rx+0x7bc/0x8c8 [ath11k])
    [  239.827757] [<c7f63d7c>] (ath11k_dp_process_rx [ath11k]) from [<c7f5b6c4>] (ath11k_dp_service_srng+0x2c0/0x2e0 [ath11k])
    [  239.838484] [<c7f5b6c4>] (ath11k_dp_service_srng [ath11k]) from [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll+0x20/0x84 [ath11k_ahb]
                )
    [  239.849419] [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll [ath11k_ahb]) from [<8073ce1c>] (net_rx_action+0xe0/0x28c)
    [  239.860945] [<8073ce1c>] (net_rx_action) from [<80324868>] (__do_softirq+0xe4/0x228)
    [  239.871269] [<80324868>] (__do_softirq) from [<80324c48>] (irq_exit+0x98/0x108)
    [  239.879080] [<80324c48>] (irq_exit) from [<8035c59c>] (__handle_domain_irq+0x90/0xb4)
    [  239.886114] [<8035c59c>] (__handle_domain_irq) from [<8030137c>] (gic_handle_irq+0x50/0x94)
    [  239.894100] [<8030137c>] (gic_handle_irq) from [<803024c0>] (__irq_svc+0x40/0x74)
    
    Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
    Link: https://lore.kernel.org/r/1616163532-3881-1-git-send-email-seevalam@codeaurora.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f666567a51fb028f731e465baacbe7fab6202abe
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Mon Apr 5 21:29:22 2021 -0700

    pcnet32: Use pci_resource_len to validate PCI resource
    
    [ Upstream commit 66c3f05ddc538ee796321210c906b6ae6fc0792a ]
    
    pci_resource_start() is not a good indicator to determine if a PCI
    resource exists or not, since the resource may start at address 0.
    This is seen when trying to instantiate the driver in qemu for riscv32
    or riscv64.
    
    pci 0000:00:01.0: reg 0x10: [io  0x0000-0x001f]
    pci 0000:00:01.0: reg 0x14: [mem 0x00000000-0x0000001f]
    ...
    pcnet32: card has no PCI IO resources, aborting
    
    Use pci_resouce_len() instead.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9e249bc38a4843f2deac014e536777d71892c93a
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:52 2021 -0400

    net: ieee802154: forbid monitor for add llsec seclevel
    
    [ Upstream commit 9ec87e322428d4734ac647d1a8e507434086993d ]
    
    This patch forbids to add llsec seclevel for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-14-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a7899eaaeb8820b52be487fbabb68cdb1edc4c3
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:51 2021 -0400

    net: ieee802154: stop dump llsec seclevels for monitors
    
    [ Upstream commit 4c9b4f55ad1f5a4b6206ac4ea58f273126d21925 ]
    
    This patch stops dumping llsec seclevels for monitors which we don't
    support yet. Otherwise we will access llsec mib which isn't initialized
    for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-13-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fc5f9c33edb5e195f5fcdb84107d1085515481cd
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:50 2021 -0400

    net: ieee802154: forbid monitor for del llsec devkey
    
    [ Upstream commit 6fb8045319ef172dc88a8142e7f8b58c7608137e ]
    
    This patch forbids to del llsec devkey for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-12-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63581374638bbabe598825b258ab642c0ccfa122
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:49 2021 -0400

    net: ieee802154: forbid monitor for add llsec devkey
    
    [ Upstream commit a347b3b394868fef15b16f143719df56184be81d ]
    
    This patch forbids to add llsec devkey for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-11-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d5ee2ee9ab25927f4da586b9934f1d79864d953
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:48 2021 -0400

    net: ieee802154: stop dump llsec devkeys for monitors
    
    [ Upstream commit 080d1a57a94d93e70f84b7a360baa351388c574f ]
    
    This patch stops dumping llsec devkeys for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-10-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c8caf78304fe2117e16e0e5ee29267ec3b9b51f
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:47 2021 -0400

    net: ieee802154: forbid monitor for del llsec dev
    
    [ Upstream commit ad8f9de1f3566686af35b1c6b43240726541da61 ]
    
    This patch forbids to del llsec dev for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-9-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c993c05b9d48c8d0aeddd3e180eff95228926625
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:46 2021 -0400

    net: ieee802154: forbid monitor for add llsec dev
    
    [ Upstream commit 5303f956b05a2886ff42890908156afaec0f95ac ]
    
    This patch forbids to add llsec dev for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-8-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f9d7088d385c0ac5a0314ecc591940c6a944416f
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:45 2021 -0400

    net: ieee802154: stop dump llsec devs for monitors
    
    [ Upstream commit 5582d641e6740839c9b83efd1fbf9bcd00b6f5fc ]
    
    This patch stops dumping llsec devs for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-7-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 178ddee28d530f52411c264f6710d4c84632fd41
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:44 2021 -0400

    net: ieee802154: forbid monitor for del llsec key
    
    [ Upstream commit b6e2949544a183f590ae6f3ef2d1aaaa2c44e38a ]
    
    This patch forbids to del llsec key for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-6-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d025404d5132e529f7b3b15b31b5d7a637d6a6a
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:43 2021 -0400

    net: ieee802154: forbid monitor for add llsec key
    
    [ Upstream commit 08470c5453339369bd3d590c4cbb0b5961cdcbb6 ]
    
    This patch forbids to add llsec key for monitor interfaces which we
    don't support yet. Otherwise we will access llsec mib which isn't
    initialized for monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-5-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d8b4f3a9d732d7ad66e4d5e5425373edc7808403
Author: Alexander Aring <aahringo@redhat.com>
Date:   Sun Apr 4 20:30:42 2021 -0400

    net: ieee802154: stop dump llsec keys for monitors
    
    [ Upstream commit fb3c5cdf88cd504ef11d59e8d656f4bc896c6922 ]
    
    This patch stops dumping llsec keys for monitors which we don't support
    yet. Otherwise we will access llsec mib which isn't initialized for
    monitors.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210405003054.256017-4-aahringo@redhat.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e16998019358fef541a6daface52678f7f164d5b
Author: Martin Wilck <mwilck@suse.com>
Date:   Thu Apr 1 11:11:05 2021 +0200

    scsi: scsi_transport_srp: Don't block target in SRP_PORT_LOST state
    
    [ Upstream commit 5cd0f6f57639c5afbb36100c69281fee82c95ee7 ]
    
    rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the
    SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with
    srp_reconnect_work(), a warning is printed:
    
    Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / host18.
    Mar 27 18:48:07 ictm1604s01h4 kernel: ------------[ cut here ]------------
    Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) failed: ret = -22
    Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace:
    Mar 27 18:48:07 ictm1604s01h4 kernel:  ? scsi_target_unblock+0x50/0x50 [scsi_mod]
    Mar 27 18:48:07 ictm1604s01h4 kernel:  starget_for_each_device+0x80/0xb0 [scsi_mod]
    Mar 27 18:48:07 ictm1604s01h4 kernel:  target_block+0x24/0x30 [scsi_mod]
    Mar 27 18:48:07 ictm1604s01h4 kernel:  device_for_each_child+0x57/0x90
    Mar 27 18:48:07 ictm1604s01h4 kernel:  srp_reconnect_rport+0xe4/0x230 [scsi_transport_srp]
    Mar 27 18:48:07 ictm1604s01h4 kernel:  srp_reconnect_work+0x40/0xc0 [scsi_transport_srp]
    
    Avoid this by not trying to block targets for rports in SRP_PORT_LOST
    state.
    
    Link: https://lore.kernel.org/r/20210401091105.8046-1-mwilck@suse.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0268d35305dc512ab9a9ca947fe4ed3d95fd350
Author: Alexander Shiyan <shc_work@mail.ru>
Date:   Fri Apr 2 11:14:05 2021 +0300

    ASoC: fsl_esai: Fix TDM slot setup for I2S mode
    
    [ Upstream commit e7a48c710defa0e0fef54d42b7d9e4ab596e2761 ]
    
    When using the driver in I2S TDM mode, the fsl_esai_startup()
    function rewrites the number of slots previously set by the
    fsl_esai_set_dai_tdm_slot() function to 2.
    To fix this, let's use the saved slot count value or, if TDM
    is not used and the number of slots is not set, the driver will use
    the default value (2), which is set by fsl_esai_probe().
    
    Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
    Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
    Link: https://lore.kernel.org/r/20210402081405.9892-1-shc_work@mail.ru
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d60837aa64be2e1872c2f458df918ee9a3c49ac6
Author: Rob Clark <robdclark@chromium.org>
Date:   Wed Mar 24 18:23:52 2021 -0700

    drm/msm: Fix a5xx/a6xx timestamps
    
    [ Upstream commit 9fbd3088351b92e8c2cef6e37a39decb12a8d5bb ]
    
    They were reading a counter that was configured to ALWAYS_COUNT (ie.
    cycles that the GPU is doing something) rather than ALWAYS_ON.  This
    isn't the thing that userspace is looking for.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Acked-by: Jordan Crouse <jordan@cosmicpenguin.net>
    Message-Id: <20210325012358.1759770-2-robdclark@gmail.com>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01e86da75c18724422a1047707367916885b5401
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 8 16:34:21 2021 +0100

    ARM: omap1: fix building with clang IAS
    
    [ Upstream commit 28399a5a6d569c9bdb612345e4933046ca37cde5 ]
    
    The clang integrated assembler fails to build one file with
    a complex asm instruction:
    
    arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: error: invalid instruction, any one of the following would fix this:
     mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
     ^
    arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: armv6t2
     mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
     ^
    arch/arm/mach-omap1/ams-delta-fiq-handler.S:249:2: note: instruction requires: thumb2
     mov r10, #(1 << (((NR_IRQS_LEGACY + 12) - NR_IRQS_LEGACY) % 32)) @ set deferred_fiq bit
     ^
    
    The problem is that 'NR_IRQS_LEGACY' is not defined here. Apparently
    gas does not care because we first add and then subtract this number,
    leading to the immediate value to be the same regardless of the
    specific definition of NR_IRQS_LEGACY.
    
    Neither the way that 'gas' just silently builds this file, nor the
    way that clang IAS makes nonsensical suggestions for how to fix it
    is great. Fortunately there is an easy fix, which is to #include
    the header that contains the definition.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Tony Lindgren <tony@atomide.com>
    Link: https://lore.kernel.org/r/20210308153430.2530616-1-arnd@kernel.org'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f02dc4d360fcbd23b5d2ecb57f53fcc9a225cff
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 23 14:18:05 2021 +0100

    ARM: keystone: fix integer overflow warning
    
    [ Upstream commit 844b85dda2f569943e1e018fdd63b6f7d1d6f08e ]
    
    clang warns about an impossible condition when building with 32-bit
    phys_addr_t:
    
    arch/arm/mach-keystone/keystone.c:79:16: error: result of comparison of constant 51539607551 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
                mem_end   > KEYSTONE_HIGH_PHYS_END) {
                ~~~~~~~   ^ ~~~~~~~~~~~~~~~~~~~~~~
    arch/arm/mach-keystone/keystone.c:78:16: error: result of comparison of constant 34359738368 with expression of type 'phys_addr_t' (aka 'unsigned int') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
            if (mem_start < KEYSTONE_HIGH_PHYS_START ||
                ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~
    
    Change the temporary variable to a fixed-size u64 to avoid the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
    Link: https://lore.kernel.org/r/20210323131814.2751750-1-arnd@kernel.org'
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3183866b3da3d8e5594e835d1cca350e2608a92
Author: Tong Zhu <zhutong@amazon.com>
Date:   Fri Mar 19 14:33:37 2021 -0400

    neighbour: Disregard DEAD dst in neigh_update
    
    [ Upstream commit d47ec7a0a7271dda08932d6208e4ab65ab0c987c ]
    
    After a short network outage, the dst_entry is timed out and put
    in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
    from this neighbour after network recovers. There is a potential
    race condition that dst_entry is still in DST_OBSOLETE_DEAD.
    With that, another neighbour lookup causes more harm than good.
    
    In best case all packets in arp_queue are lost. This is
    counterproductive to the original goal of finding a better path
    for those packets.
    
    I observed a worst case with 4.x kernel where a dst_entry in
    DST_OBSOLETE_DEAD state is associated with loopback net_device.
    It leads to an ethernet header with all zero addresses.
    A packet with all zero source MAC address is quite deadly with
    mac80211, ath9k and 802.11 block ack.  It fails
    ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). Ath9k flushes tx
    queue (ath_tx_complete_aggr). BAW (block ack window) is not
    updated. BAW logic is damaged and ath9k transmission is disabled.
    
    Signed-off-by: Tong Zhu <zhutong@amazon.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cf8b48a4de20eb1d76326a15b641e85d424a698
Author: Ryan Lee <ryans.lee@maximintegrated.com>
Date:   Wed Mar 24 20:35:54 2021 -0700

    ASoC: max98373: Added 30ms turn on/off time delay
    
    [ Upstream commit 3a27875e91fb9c29de436199d20b33f9413aea77 ]
    
    Amp requires 10 ~ 30ms for the power ON and OFF.
    Added 30ms delay for stability.
    
    Signed-off-by: Ryan Lee <ryans.lee@maximintegrated.com>
    Link: https://lore.kernel.org/r/20210325033555.29377-2-ryans.lee@maximintegrated.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47d04c039915346993330ebbd4dfe028001d016b
Author: Wang Qing <wangqing@vivo.com>
Date:   Mon Mar 1 20:05:48 2021 +0800

    arc: kernel: Return -EFAULT if copy_to_user() fails
    
    [ Upstream commit 46e152186cd89d940b26726fff11eb3f4935b45a ]
    
    The copy_to_user() function returns the number of bytes remaining to be
    copied, but we want to return -EFAULT if the copy doesn't complete.
    
    Signed-off-by: Wang Qing <wangqing@vivo.com>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68bd0d8ab19ecefeb591baa4d8c3fe3f9852792f
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun Mar 21 15:49:13 2021 +0900

    lockdep: Add a missing initialization hint to the "INFO: Trying to register non-static key" message
    
    [ Upstream commit 3a85969e9d912d5dd85362ee37b5f81266e00e77 ]
    
    Since this message is printed when dynamically allocated spinlocks (e.g.
    kzalloc()) are used without initialization (e.g. spin_lock_init()),
    suggest to developers to check whether initialization functions for objects
    were called, before making developers wonder what annotation is missing.
    
    [ mingo: Minor tweaks to the message. ]
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20210321064913.4619-1-penguin-kernel@I-love.SAKURA.ne.jp
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ffc9f854d238d94c51a778aba17c27b50c78b11
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 8 11:30:45 2021 +0200

    ARM: dts: Fix moving mmc devices with aliases for omap4 & 5
    
    [ Upstream commit 77335a040178a0456d4eabc8bf17a7ca3ee4a327 ]
    
    Fix moving mmc devices with dts aliases as discussed on the lists.
    Without this we now have internal eMMC mmc1 show up as mmc2 compared
    to the earlier order of devices.
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4609d27ca6e462e679308ad4da063df84c9c9ee6
Author: Tony Lindgren <tony@atomide.com>
Date:   Mon Mar 8 11:26:25 2021 +0200

    ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable race
    
    [ Upstream commit 140a776833957539c84301dbdb4c3013876de118 ]
    
    We have a duplicate legacy clock defined for sha2md5_fck that can
    sometimes race with clk_disable() with the dts configured clock
    for OMAP4_SHA2MD5_CLKCTRL when unused clocks are disabled during
    boot causing an "Unhandled fault: imprecise external abort".
    
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09db44ad36b0fce4a4c84607c32d1c613a5c7e4c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Wed Mar 24 16:17:57 2021 +0200

    dmaengine: dw: Make it dependent to HAS_IOMEM
    
    [ Upstream commit 88cd1d6191b13689094310c2405394e4ce36d061 ]
    
    Some architectures do not provide devm_*() APIs. Hence make the driver
    dependent on HAVE_IOMEM.
    
    Fixes: dbde5c2934d1 ("dw_dmac: use devm_* functions to simplify code")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Link: https://lore.kernel.org/r/20210324141757.24710-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5130cda3cb1fcc5f4e5c08ff3fba87171c5b3c80
Author: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Date:   Mon Mar 29 14:41:12 2021 +0300

    gpio: sysfs: Obey valid_mask
    
    [ Upstream commit 23cf00ddd2e1aacf1873e43f5e0c519c120daf7a ]
    
    Do not allow exporting GPIOs which are set invalid
    by the driver's valid mask.
    
    Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property")
    Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2dce5702ef054c118a13fdf36e8e145838036b99
Author: Fabian Vogt <fabian@ritter-vogt.de>
Date:   Tue Mar 23 10:45:55 2021 -0700

    Input: nspire-keypad - enable interrupts only when opened
    
    [ Upstream commit 69d5ff3e9e51e23d5d81bf48480aa5671be67a71 ]
    
    The driver registers an interrupt handler in _probe, but didn't configure
    them until later when the _open function is called. In between, the keypad
    can fire an IRQ due to touchpad activity, which the handler ignores. This
    causes the kernel to disable the interrupt, blocking the keypad from
    working.
    
    Fix this by disabling interrupts before registering the handler.
    Additionally, disable them in _close, so that they're only enabled while
    open.
    
    Fixes: fc4f31461892 ("Input: add TI-Nspire keypad support")
    Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de>
    Link: https://lore.kernel.org/r/3383725.iizBOSrK1V@linux-e202.suse.de
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6180d2274b17fc0473fb0764d3417c0bddb99b2e
Author: Or Cohen <orcohen@paloaltonetworks.com>
Date:   Tue Apr 13 21:10:31 2021 +0300

    net/sctp: fix race condition in sctp_destroy_sock
    
    commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b upstream.
    
    If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock
    held and sp->do_auto_asconf is true, then an element is removed
    from the auto_asconf_splist without any proper locking.
    
    This can happen in the following functions:
    1. In sctp_accept, if sctp_sock_migrate fails.
    2. In inet_create or inet6_create, if there is a bpf program
       attached to BPF_CGROUP_INET_SOCK_CREATE which denies
       creation of the sctp socket.
    
    The bug is fixed by acquiring addr_wq_lock in sctp_destroy_sock
    instead of sctp_close.
    
    This addresses CVE-2021-23133.
    
    Reported-by: Or Cohen <orcohen@paloaltonetworks.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications")
    Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 304c21786b015b9c3b44e656fea204624b608702
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Dec 17 14:06:05 2019 -0800

    scsi: qla2xxx: Fix fabric scan hang
    
    [ Upstream commit f57a0107359605b29f4ea9afb8ee2e03473b1448 ]
    
    On timeout, SRB pointer was cleared from outstanding command array and
    dropped.  It was not allowed to go through the done process and cleanup.
    This patch will abort the SRB where FW will return it with an error status
    and resume the normal cleanup.
    
    Link: https://lore.kernel.org/r/20191217220617.28084-3-hmadhani@marvell.com
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca0188d396cd467e44ee9f28f81e93a4957d7cc4
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Dec 17 14:06:11 2019 -0800

    scsi: qla2xxx: Fix stuck login session using prli_pend_timer
    
    [ Upstream commit 8aaac2d7da873aebeba92c666f82c00bbd74aaf9 ]
    
    Session is stuck if driver sees FW has received a PRLI. Driver allows FW to
    finish with processing of PRLI by checking back with FW at a later time to
    see if the PRLI has finished. Instead, driver failed to push forward after
    re-checking PRLI completion.
    
    Fixes: ce0ba496dccf ("scsi: qla2xxx: Fix stuck login session")
    Cc: stable@vger.kernel.org # 5.3
    Link: https://lore.kernel.org/r/20191217220617.28084-9-hmadhani@marvell.com
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c393c7f77cf832dae46d00d558e2bb085b3e4028
Author: Shyam Sundar <ssundar@marvell.com>
Date:   Tue Dec 17 14:06:06 2019 -0800

    scsi: qla2xxx: Add a shadow variable to hold disc_state history of fcport
    
    [ Upstream commit 27258a5771446f9c7edc929ecb76fe2c12c29d97 ]
    
    This patch adds a shadow variable to hold disc_state history for the fcport
    and prints state transition when the logging is enabled.
    
    Link: https://lore.kernel.org/r/20191217220617.28084-4-hmadhani@marvell.com
    Signed-off-by: Shyam Sundar <ssundar@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad66dc6d883077b4a12b98da0d2b4eff3f59eb1e
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Nov 5 07:06:50 2019 -0800

    scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure
    
    [ Upstream commit 983f127603fac650fa34ee69db363e4615eaf9e7 ]
    
    Current code will send PRLI with FC-NVMe bit set for the targets which
    support only FCP. This may result into issue with targets which do not
    understand NVMe and will go into a strange state. This patch would restart
    the login process by going back to PLOGI state. The PLOGI state will force
    the target to respond to correct PRLI request.
    
    Fixes: c76ae845ea836 ("scsi: qla2xxx: Add error handling for PLOGI ELS passthrough")
    Cc: stable@vger.kernel.org # 5.4
    Link: https://lore.kernel.org/r/20191105150657.8092-2-hmadhani@marvell.com
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8b5e82aea7b39a6b19af2077f187fbe5b4ebf3d8
Author: Arun Easi <aeasi@marvell.com>
Date:   Tue Nov 5 07:06:56 2019 -0800

    scsi: qla2xxx: Fix device connect issues in P2P configuration
    
    [ Upstream commit 65e9200938052ce90f24421bb057e1be1d6147c7 ]
    
    P2P needs to take the alternate plogi route.
    
    Link: https://lore.kernel.org/r/20191105150657.8092-8-hmadhani@marvell.com
    Reviewed-by: Ewan D. Milne <emilne@redhat.com>
    Signed-off-by: Arun Easi <aeasi@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8eed34d3c444c23a0a8ebfdaf92972639a7273a0
Author: Michael Hernandez <mhernandez@marvell.com>
Date:   Thu Sep 12 11:09:12 2019 -0700

    scsi: qla2xxx: Dual FCP-NVMe target port support
    
    [ Upstream commit 84ed362ac40ca44dbbbebf767301463aa72bc797 ]
    
    Some storage arrays advertise FCP LUNs and NVMe namespaces behind the same
    WWN.  The driver now offers a user option by way of NVRAM parameter to
    allow users to choose, on a per port basis, the kind of FC-4 type they
    would like to prioritize for login.
    
    Link: https://lore.kernel.org/r/20190912180918.6436-9-hmadhani@marvell.com
    Signed-off-by: Michael Hernandez <mhernandez@marvell.com>
    Signed-off-by: Himanshu Madhani <hmadhani@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33beb0e6c244a119051401dda0e4b735fe8999a1
Author: Sasha Levin <sashal@kernel.org>
Date:   Fri Apr 16 09:48:48 2021 -0400

    Revert "scsi: qla2xxx: Fix stuck login session using prli_pend_timer"
    
    This reverts commit 0b84591fdd5ea3ca0d93aaea489353f0381832c0.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94ac0a8866c4cbc375f7dd34ad67976960297a45
Author: Sasha Levin <sashal@kernel.org>
Date:   Fri Apr 16 09:48:38 2021 -0400

    Revert "scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure"
    
    This reverts commit 74924e407bf74667b07430f785a104371be097af.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>