commit 4938296e03bd227e5020d63d418956fe52baf97c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jul 20 16:16:16 2021 +0200

    Linux 4.19.198
    
    Link: https://lore.kernel.org/r/20210719144946.310399455@linuxfoundation.org
    Link: https://lore.kernel.org/r/20210719184335.198051502@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6de9f0bf7cacc772a618699f9ed5c9f6fca58a1d
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Tue Jul 13 17:49:23 2021 +0200

    seq_file: disallow extremely large seq buffer allocations
    
    commit 8cae8cd89f05f6de223d63e6d15e31c8ba9cf53b upstream.
    
    There is no reasonable need for a buffer larger than this, and it avoids
    int overflow pitfalls.
    
    Fixes: 058504edd026 ("fs/seq_file: fallback to vmalloc allocation")
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Reported-by: Qualys Security Advisory <qsa@qualys.com>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c021be62bbcbf5435ec89713ed542040196f5b89
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jun 3 15:33:20 2021 +0300

    scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()
    
    commit 80927822e8b6be46f488524cd7d5fe683de97fc4 upstream.
    
    The "retval" variable needs to be signed for the error handling to work.
    
    Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda
    Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value")
    Reviewed-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e70bf39b1a96b40ab13044729613a913b46cddd
Author: Nikolay Aleksandrov <nikolay@nvidia.com>
Date:   Sun Jul 11 12:56:28 2021 +0300

    net: bridge: multicast: fix PIM hello router port marking race
    
    commit 04bef83a3358946bfc98a5ecebd1b0003d83d882 upstream.
    
    When a PIM hello packet is received on a bridge port with multicast
    snooping enabled, we mark it as a router port automatically, that
    includes adding that port the router port list. The multicast lock
    protects that list, but it is not acquired in the PIM message case
    leading to a race condition, we need to take it to fix the race.
    
    Cc: stable@vger.kernel.org
    Fixes: 91b02d3d133b ("bridge: mcast: add router port on PIM hello message")
    Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8553099bdbe95a717e974552b6e6dbb8c4dac70b
Author: Martin Fäcknitz <faecknitz@hotsplots.de>
Date:   Mon Jul 5 02:03:54 2021 +0200

    MIPS: vdso: Invalid GIC access through VDSO
    
    [ Upstream commit 47ce8527fbba145a7723685bc9a27d9855e06491 ]
    
    Accessing raw timers (currently only CLOCK_MONOTONIC_RAW) through VDSO
    doesn't return the correct time when using the GIC as clock source.
    The address of the GIC mapped page is in this case not calculated
    correctly. The GIC mapped page is calculated from the VDSO data by
    subtracting PAGE_SIZE:
    
      void *get_gic(const struct vdso_data *data) {
        return (void __iomem *)data - PAGE_SIZE;
      }
    
    However, the data pointer is not page aligned for raw clock sources.
    This is because the VDSO data for raw clock sources (CS_RAW = 1) is
    stored after the VDSO data for coarse clock sources (CS_HRES_COARSE = 0).
    Therefore, only the VDSO data for CS_HRES_COARSE is page aligned:
    
      +--------------------+
      |                    |
      | vd[CS_RAW]         | ---+
      | vd[CS_HRES_COARSE] |    |
      +--------------------+    | -PAGE_SIZE
      |                    |    |
      |  GIC mapped page   | <--+
      |                    |
      +--------------------+
    
    When __arch_get_hw_counter() is called with &vd[CS_RAW], get_gic returns
    the wrong address (somewhere inside the GIC mapped page). The GIC counter
    values are not returned which results in an invalid time.
    
    Fixes: a7f4df4e21dd ("MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()")
    Signed-off-by: Martin Fäcknitz <faecknitz@hotsplots.de>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d822ebccccf11c10b488a8b13fff8e7fdbce97b7
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sun Jul 4 16:02:11 2021 -0700

    mips: disable branch profiling in boot/decompress.o
    
    [ Upstream commit 97e488073cfca0eea84450169ca4cbfcc64e33e3 ]
    
    Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o
    to prevent linkage errors.
    
    mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict':
    decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update'
    mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update'
    mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update'
    mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update'
    mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update'
    mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow
    
    Fixes: e76e1fdfa8f8 ("lib: add support for LZ4-compressed kernel")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Cc: linux-mips@vger.kernel.org
    Cc: Kyungsik Lee <kyungsik.lee@lge.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c5bc66b33f6ab5f8792920beb821e1041586b44
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Jul 2 16:28:37 2021 +0200

    mips: always link byteswap helpers into decompressor
    
    [ Upstream commit cddc40f5617e53f97ef019d5b29c1bd6cbb031ec ]
    
    My series to clean up the unaligned access implementation
    across architectures caused some mips randconfig builds to
    fail with:
    
       mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel':
       decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2'
    
    It turns out that this problem has already been fixed for the XZ
    decompressor but now it also shows up in (at least) LZO and LZ4.  From my
    analysis I concluded that the compiler could always have emitted those
    calls, but the different implementation allowed it to make otherwise
    better decisions about not inlining the byteswap, which results in the
    link error when the out-of-line code is missing.
    
    While it could be addressed by adding it to the two decompressor
    implementations that are known to be affected, but as this only adds
    112 bytes to the kernel, the safer choice is to always add them.
    
    Fixes: c50ec6787536 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions")
    Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers")
    Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/
    Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/
    Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/
    Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5b02f5892657f385502c93ab42289ea4fbf05cf1
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 12 09:18:34 2021 +0200

    scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()
    
    [ Upstream commit 030e4138d11fced3b831c2761e4cecf347bae99c ]
    
    If an error occurs after a pci_enable_pcie_error_reporting() call, it must
    be undone by a corresponding pci_disable_pcie_error_reporting() call, as
    already done in the remove function.
    
    Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr
    Fixes: 3567f36a09d1 ("[SCSI] be2iscsi: Fix AER handling in driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83723802bdb17310228a1414ea4ec4bd78720d8b
Author: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Date:   Wed May 26 12:54:00 2021 +0200

    ARM: dts: imx6q-dhcom: Add gpios pinctrl for i2c bus recovery
    
    [ Upstream commit ddc873cd3c0af4faad6a00bffda21c3f775126dd ]
    
    The i2c bus can freeze at the end of transaction so the bus can no longer work.
    This scenario is improved by adding scl/sda gpios definitions to implement the
    i2c bus recovery mechanism.
    
    Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
    Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: kernel@dh-electronics.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2b230a965c9b2eab0cca13f84aa54df022b11dc7
Author: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Date:   Wed May 26 12:53:59 2021 +0200

    ARM: dts: imx6q-dhcom: Fix ethernet plugin detection problems
    
    [ Upstream commit e2bdd3484890441b9cc2560413a86e8f2aa04157 ]
    
    To make the ethernet cable plugin detection reliable the
    power detection of the smsc phy has been disabled.
    
    Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
    Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: kernel@dh-electronics.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 63a9a35c848bc66955ffad8874011aed354722ad
Author: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Date:   Wed May 26 12:53:58 2021 +0200

    ARM: dts: imx6q-dhcom: Fix ethernet reset time properties
    
    [ Upstream commit c016c26c1631f539c652b5d82242a3ca402545c1 ]
    
    Fix ethernet reset time properties as described in
    Documentation/devicetree/bindings/net/ethernet-phy.yaml
    
    Fixes: 52c7a088badd ("ARM: dts: imx6q: Add support for the DHCOM iMX6 SoM and PDK2")
    Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: kernel@dh-electronics.com
    To: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit caef06c17f64e351dc1eb91b5341e445bceab1d5
Author: Aswath Govindraju <a-govindraju@ti.com>
Date:   Tue Jun 8 10:39:52 2021 +0530

    ARM: dts: am437x: align ti,pindir-d0-out-d1-in property with dt-shema
    
    [ Upstream commit 9b11fec7345f21995f4ea4bafb0e108b9a620238 ]
    
    ti,pindir-d0-out-d1-in property is expected to be of type boolean.
    Therefore, fix the property accordingly.
    
    Fixes: b0b039515445 ("ARM: dts: am43x-epos-evm: set data pin directions for spi0 and spi1")
    Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 306e7bdd55083d1b2c471f6f3d88bac9ca72ec90
Author: Aswath Govindraju <a-govindraju@ti.com>
Date:   Tue Jun 8 10:39:51 2021 +0530

    ARM: dts: am335x: align ti,pindir-d0-out-d1-in property with dt-shema
    
    [ Upstream commit 414bfe1d26b60ef20b58e36efd5363188a694bab ]
    
    ti,pindir-d0-out-d1-in property is expected to be of type boolean.
    Therefore, fix the property accordingly.
    
    Fixes: 444d66fafab8 ("ARM: dts: add spi wifi support to cm-t335")
    Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee1aa737ba0b75ab8af3444c4ae5bdba36aed6e6
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Thu May 27 11:43:22 2021 -0400

    memory: fsl_ifc: fix leak of private memory on probe failure
    
    [ Upstream commit 8e0d09b1232d0538066c40ed4c13086faccbdff6 ]
    
    On probe error the driver should free the memory allocated for private
    structure.  Fix this by using resource-managed allocation.
    
    Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210527154322.81253-2-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 94bc2fe46102d1e060fc749c0c19511e76c9995f
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Thu May 27 11:43:21 2021 -0400

    memory: fsl_ifc: fix leak of IO mapping on probe failure
    
    [ Upstream commit 3b132ab67fc7a358fff35e808fa65d4bea452521 ]
    
    On probe error the driver should unmap the IO memory.  Smatch reports:
    
      drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.
    
    Fixes: a20cbdeffce2 ("powerpc/fsl: Add support for Integrated Flash Controller")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210527154322.81253-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4bb145e596e9308d086b336a61794f0c331c4f34
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Mon Jun 7 10:26:15 2021 +0200

    reset: bail if try_module_get() fails
    
    [ Upstream commit 4fb26fb83f0def3d39c14e268bcd4003aae8fade ]
    
    Abort instead of returning a new reset control for a reset controller
    device that is going to have its module unloaded.
    
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Fixes: 61fc41317666 ("reset: Add reset controller API")
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/20210607082615.15160-1-p.zabel@pengutronix.de
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cb5a0522b5f6a15e9223d3a315c2e0041e02550
Author: Rafał Miłecki <rafal@milecki.pl>
Date:   Wed May 12 15:07:09 2021 +0200

    ARM: dts: BCM5301X: Fixup SPI binding
    
    [ Upstream commit d5aede3e6dd1b8ca574600a1ecafe1e580c53f2f ]
    
    1. Reorder interrupts
    2. Fix typo: s/spi_lr_overhead/spi_lr_overread/
    3. Rename node: s/spi-nor@0/flash@0/
    
    This fixes:
    arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi@18029200: interrupt-names: 'oneOf' conditional failed, one must be fixed:
            ['spi_lr_fullness_reached', 'spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted'] is too long
            Additional items are not allowed ('spi_lr_session_aborted', 'spi_lr_impatient', 'spi_lr_session_done', 'spi_lr_overhead', 'mspi_done', 'mspi_halted' were unexpected)
            'mspi_done' was expected
            'spi_l1_intr' was expected
            'mspi_halted' was expected
            'spi_lr_fullness_reached' was expected
            'spi_lr_session_aborted' was expected
            'spi_lr_impatient' was expected
            'spi_lr_session_done' was expected
            'spi_lr_overread' was expected
            From schema: Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
    arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: spi-nor@0: $nodename:0: 'spi-nor@0' does not match '^flash(@.*)?$'
            From schema: Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
    
    Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7d307d042247110ed675ca607f32b2957e190cec
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Apr 29 14:41:15 2021 +0200

    ARM: dts: r8a7779, marzen: Fix DU clock names
    
    [ Upstream commit 6ab8c23096a29b69044209a5925758a6f88bd450 ]
    
    "make dtbs_check" complains:
    
        arch/arm/boot/dts/r8a7779-marzen.dt.yaml: display@fff80000: clock-names:0: 'du.0' was expected
    
    Change the first clock name to match the DT bindings.
    This has no effect on actual operation, as the Display Unit driver in
    Linux does not use the first clock name on R-Car H1, but just grabs the
    first clock.
    
    Fixes: 665d79aa47cb3983 ("ARM: shmobile: marzen: Add DU external pixel clock to DT")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/9d5e1b371121883b3b3e10a3df43802a29c6a9da.1619699965.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52d479b28e44971039c2c7463a6a81463d4fd486
Author: Valentine Barshak <valentine.barshak@cogentembedded.com>
Date:   Fri Mar 26 13:10:50 2021 +0100

    arm64: dts: renesas: v3msk: Fix memory size
    
    [ Upstream commit a422ec20caef6a50cf3c1efa93538888ebd576a6 ]
    
    The V3MSK board has 2 GiB RAM according to the datasheet and schematics.
    
    Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
    [geert: Verified schematics]
    Fixes: cc3e267e9bb0ce7f ("arm64: dts: renesas: initial V3MSK board device tree")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/20210326121050.1578460-1-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1cae2aece5bc508d4a9fc29764669930528fefbc
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 11 10:19:26 2021 +0300

    rtc: fix snprintf() checking in is_rtc_hctosys()
    
    [ Upstream commit 54b909436ede47e0ee07f1765da27ec2efa41e84 ]
    
    The scnprintf() function silently truncates the printf() and returns
    the number bytes that it was able to copy (not counting the NUL
    terminator).  Thus, the highest value it can return here is
    "NAME_SIZE - 1" and the overflow check is dead code.  Fix this by
    using the snprintf() function which returns the number of bytes that
    would have been copied if there was enough space and changing the
    condition from "> NAME_SIZE" to ">= NAME_SIZE".
    
    Fixes: 92589c986b33 ("rtc-proc: permit the /proc/driver/rtc device to use other devices")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/YJov/pcGmhLi2pEl@mwanda
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2d713c0f74582354f1f1768b368cebb5dca190e
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Fri Apr 23 12:18:15 2021 +0200

    memory: atmel-ebi: add missing of_node_put for loop iteration
    
    [ Upstream commit 907c5bbb514a4676160e79764522fff56ce3448e ]
    
    Early exits from for_each_available_child_of_node() should decrement the
    node reference counter.  Reported by Coccinelle:
    
      drivers/memory/atmel-ebi.c:593:1-33: WARNING:
        Function "for_each_available_child_of_node" should have of_node_put() before return around line 604.
    
    Fixes: 6a4ec4cd0888 ("memory: add Atmel EBI (External Bus Interface) driver")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210423101815.119341-2-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2408a5e8d7f1f2f0a2daddf502ef8572df784e22
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Wed May 5 09:59:41 2021 -0400

    ARM: dts: exynos: fix PWM LED max brightness on Odroid XU4
    
    [ Upstream commit fd2f1717966535b7d0b6fe45cf0d79e94330da5f ]
    
    There is no "max_brightness" property as pointed out by dtschema:
    
      arch/arm/boot/dts/exynos5422-odroidxu4.dt.yaml: led-controller: led-1: 'max-brightness' is a required property
    
    Fixes: 6658356014cb ("ARM: dts: Add support Odroid XU4 board for exynos5422-odroidxu4")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210505135941.59898-5-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88d7b6aeec87d64a39407aa411caf4ac744a2421
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Wed May 5 09:59:40 2021 -0400

    ARM: dts: exynos: fix PWM LED max brightness on Odroid HC1
    
    [ Upstream commit a7e59c84cf2055a1894f45855c8319191f2fa59e ]
    
    There is no "max_brightness" property as pointed out by dtschema:
    
      arch/arm/boot/dts/exynos5422-odroidhc1.dt.yaml: led-controller: led-1: 'max-brightness' is a required property
    
    Fixes: 1ac49427b566 ("ARM: dts: exynos: Add support for Hardkernel's Odroid HC1 board")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210505135941.59898-4-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a4b928b0339b0ecbb40c9e408fe9350c57a6e44
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Wed May 5 09:59:39 2021 -0400

    ARM: dts: exynos: fix PWM LED max brightness on Odroid XU/XU3
    
    [ Upstream commit 75121e1dc9fe4def41e63d57f6a53749b88006ed ]
    
    There is no "max_brightness" property.  This brings the intentional
    brightness reduce of green LED and dtschema checks as well:
    
      arch/arm/boot/dts/exynos5410-odroidxu.dt.yaml: led-controller-1: led-1: 'max-brightness' is a required property
    
    Fixes: 719f39fec586 ("ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210505135941.59898-3-krzysztof.kozlowski@canonical.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2e98a83f55b461a20dcaca5f6e0a7104eaf5008d
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date:   Fri May 7 07:28:03 2021 -0400

    reset: a10sr: add missing of_match_table reference
    
    [ Upstream commit 466ba3c8ff4fae39e455ff8d080b3d5503302765 ]
    
    The driver defined of_device_id table but did not use it with
    of_match_table.  This prevents usual matching via devicetree and causes
    a W=1 warning:
    
      drivers/reset/reset-a10sr.c:111:34: warning:
        ‘a10sr_reset_of_match’ defined but not used [-Wunused-const-variable=]
    
    Reported-by: kernel test robot <lkp@intel.com>
    Fixes: 627006820268 ("reset: Add Altera Arria10 SR Reset Controller")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
    Link: https://lore.kernel.org/r/20210507112803.20012-1-krzysztof.kozlowski@canonical.com
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86c9c442c04084814f0ab14abccb16dae22d62fe
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Jul 7 18:07:41 2021 -0700

    hexagon: use common DISCARDS macro
    
    [ Upstream commit 681ba73c72302214686401e707e2087ed11a6556 ]
    
    ld.lld warns that the '.modinfo' section is not currently handled:
    
    ld.lld: warning: kernel/built-in.a(workqueue.o):(.modinfo) is being placed in '.modinfo'
    ld.lld: warning: kernel/built-in.a(printk/printk.o):(.modinfo) is being placed in '.modinfo'
    ld.lld: warning: kernel/built-in.a(irq/spurious.o):(.modinfo) is being placed in '.modinfo'
    ld.lld: warning: kernel/built-in.a(rcu/update.o):(.modinfo) is being placed in '.modinfo'
    
    The '.modinfo' section was added in commit 898490c010b5 ("moduleparam:
    Save information about built-in modules in separate file") to the DISCARDS
    macro but Hexagon has never used that macro.  The unification of DISCARDS
    happened in commit 023bf6f1b8bf ("linker script: unify usage of discard
    definition") in 2009, prior to Hexagon being added in 2011.
    
    Switch Hexagon over to the DISCARDS macro so that anything that is
    expected to be discarded gets discarded.
    
    Link: https://lkml.kernel.org/r/20210521011239.1332345-3-nathan@kernel.org
    Fixes: e95bf452a9e2 ("Hexagon: Add configuration and makefiles for the Hexagon architecture.")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Acked-by: Brian Cain <bcain@codeaurora.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Oliver Glitta <glittao@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3eeeaed0a54f664b025f290a819897af8a1eccc
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Sat Jul 3 14:34:20 2021 -0400

    NFSv4/pNFS: Don't call _nfs4_pnfs_v3_ds_connect multiple times
    
    [ Upstream commit f46f84931a0aa344678efe412d4b071d84d8a805 ]
    
    After we grab the lock in nfs4_pnfs_ds_connect(), there is no check for
    whether or not ds->ds_clp has already been initialised, so we can end up
    adding the same transports multiple times.
    
    Fixes: fc821d59209d ("pnfs/NFSv4.1: Add multipath capabilities to pNFS flexfiles servers over NFSv3")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8f7d42d54aa5b5d6965675a7202ccc7813c43265
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Wed Jul 7 15:40:51 2021 +0800

    ALSA: isa: Fix error return code in snd_cmi8330_probe()
    
    [ Upstream commit 31028cbed26a8afa25533a10425ffa2ab794c76c ]
    
    When 'SB_HW_16' check fails, the error code -ENODEV instead of 0 should be
    returned, which is the same as that returned when 'WSS_HW_CMI8330' check
    fails.
    
    Fixes: 43bcd973d6d0 ("[ALSA] Add snd_card_set_generic_dev() call to ISA drivers")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210707074051.2663-1-thunder.leizhen@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eede0a76a4adb097d0b4e0e0b678c4297b5c1cef
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Tue Apr 13 01:35:26 2021 -0400

    virtio_net: move tx vq operation under tx queue lock
    
    [ Upstream commit 5a2f966d0f3fa0ef6dada7ab9eda74cacee96b8a ]
    
    It's unsafe to operate a vq from multiple threads.
    Unfortunately this is exactly what we do when invoking
    clean tx poll from rx napi.
    Same happens with napi-tx even without the
    opportunistic cleaning from the receive interrupt: that races
    with processing the vq in start_xmit.
    
    As a fix move everything that deals with the vq to under tx lock.
    
    Fixes: b92f1e6751a6 ("virtio-net: transmit napi")
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fecb9b7b06ee288103f0f687b57cb033c96c54ca
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jun 23 14:01:35 2021 +0200

    x86/fpu: Limit xstate copy size in xstateregs_set()
    
    [ Upstream commit 07d6688b22e09be465652cf2da0da6bf86154df6 ]
    
    If the count argument is larger than the xstate size, this will happily
    copy beyond the end of xstate.
    
    Fixes: 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES")
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Reviewed-by: Andy Lutomirski <luto@kernel.org>
    Reviewed-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20210623121452.120741557@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 778beee03794ee5990dbc9ba14ad1d492f3df8c1
Author: Sandor Bodo-Merle <sbodomerle@gmail.com>
Date:   Tue Jun 22 17:26:30 2021 +0200

    PCI: iproc: Support multi-MSI only on uniprocessor kernel
    
    [ Upstream commit 2dc0a201d0f59e6818ef443609f0850a32910844 ]
    
    The interrupt affinity scheme used by this driver is incompatible with
    multi-MSI as it implies moving the doorbell address to that of another MSI
    group.  This isn't possible for multi-MSI, as all the MSIs must have the
    same doorbell address. As such it is restricted to systems with a single
    CPU.
    
    Link: https://lore.kernel.org/r/20210622152630.40842-2-sbodomerle@gmail.com
    Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
    Reported-by: Marc Zyngier <maz@kernel.org>
    Signed-off-by: Sandor Bodo-Merle <sbodomerle@gmail.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Pali Rohár <pali@kernel.org>
    Acked-by: Ray Jui <ray.jui@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99f8eae65c82d7f947349a45e866510e65109d79
Author: Sandor Bodo-Merle <sbodomerle@gmail.com>
Date:   Tue Jun 22 17:26:29 2021 +0200

    PCI: iproc: Fix multi-MSI base vector number allocation
    
    [ Upstream commit e673d697b9a234fc3544ac240e173cef8c82b349 ]
    
    Commit fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
    introduced multi-MSI support with a broken allocation mechanism (it failed
    to reserve the proper number of bits from the inner domain).  Natural
    alignment of the base vector number was also not guaranteed.
    
    Link: https://lore.kernel.org/r/20210622152630.40842-1-sbodomerle@gmail.com
    Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs")
    Reported-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Sandor Bodo-Merle <sbodomerle@gmail.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Acked-by: Pali Rohár <pali@kernel.org>
    Acked-by: Ray Jui <ray.jui@broadcom.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6afff12ac74a5e5eef4b6656a07de24080b712a
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Jun 18 16:11:03 2021 +0800

    ubifs: Set/Clear I_LINKABLE under i_lock for whiteout inode
    
    [ Upstream commit a801fcfeef96702fa3f9b22ad56c5eb1989d9221 ]
    
    xfstests-generic/476 reports a warning message as below:
    
    WARNING: CPU: 2 PID: 30347 at fs/inode.c:361 inc_nlink+0x52/0x70
    Call Trace:
      do_rename+0x502/0xd40 [ubifs]
      ubifs_rename+0x8b/0x180 [ubifs]
      vfs_rename+0x476/0x1080
      do_renameat2+0x67c/0x7b0
      __x64_sys_renameat2+0x6e/0x90
      do_syscall_64+0x66/0xe0
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Following race case can cause this:
             rename_whiteout(Thread 1)             wb_workfn(Thread 2)
    ubifs_rename
      do_rename
                                              __writeback_single_inode
                                                spin_lock(&inode->i_lock)
        whiteout->i_state |= I_LINKABLE
                                                inode->i_state &= ~dirty;
    ---- How race happens on i_state:
        (tmp = whiteout->i_state | I_LINKABLE)
                                               (tmp = inode->i_state & ~dirty)
        (whiteout->i_state = tmp)
                                               (inode->i_state = tmp)
    ----
                                                spin_unlock(&inode->i_lock)
        inc_nlink(whiteout)
        WARN_ON(!(inode->i_state & I_LINKABLE)) !!!
    
    Fix to add i_lock to avoid i_state update race condition.
    
    Fixes: 9e0a1fff8db56ea ("ubifs: Implement RENAME_WHITEOUT")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0704f617040c397ae73c1f88f3956787ec5d6529
Author: Gao Xiang <hsiangkao@linux.alibaba.com>
Date:   Fri Jun 18 12:20:55 2021 +0800

    nfs: fix acl memory leak of posix_acl_create()
    
    [ Upstream commit 1fcb6fcd74a222d9ead54d405842fc763bb86262 ]
    
    When looking into another nfs xfstests report, I found acl and
    default_acl in nfs3_proc_create() and nfs3_proc_mknod() error
    paths are possibly leaked. Fix them in advance.
    
    Fixes: 013cdf1088d7 ("nfs: use generic posix ACL infrastructure for v3 Posix ACLs")
    Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
    Cc: Anna Schumaker <anna.schumaker@netapp.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 14150b631675f3f4b2a1853ff07ebe594c0aa6a6
Author: Tao Ren <rentao.bupt@gmail.com>
Date:   Fri Apr 16 20:42:49 2021 -0700

    watchdog: aspeed: fix hardware timeout calculation
    
    [ Upstream commit e7dc481c92060f9ce872878b0b7a08c24713a7e5 ]
    
    Fix hardware timeout calculation in aspeed_wdt_set_timeout function to
    ensure the reload value does not exceed the hardware limit.
    
    Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver")
    Reported-by: Amithash Prasad <amithash@fb.com>
    Signed-off-by: Tao Ren <rentao.bupt@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210417034249.5978-1-rentao.bupt@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc91a4549be87e82cf3174508fedd564e265c151
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 11:22:39 2021 +0800

    um: fix error return code in winch_tramp()
    
    [ Upstream commit ccf1236ecac476d9d2704866d9a476c86e387971 ]
    
    Fix to return a negative error code from the error handling case instead
    of 0, as done elsewhere in this function.
    
    Fixes: 89df6bfc0405 ("uml: DEBUG_SHIRQ fixes")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Acked-By: anton.ivanov@cambridgegreys.com
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33a260142e15159b7cb4591000abe5e7d667a8c1
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 11:13:54 2021 +0800

    um: fix error return code in slip_open()
    
    [ Upstream commit b77e81fbe5f5fb4ad9a61ec80f6d1e30b6da093a ]
    
    Fix to return a negative error code from the error handling case instead
    of 0, as done elsewhere in this function.
    
    Fixes: a3c77c67a443 ("[PATCH] uml: slirp and slip driver cleanups and fixes")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Acked-By: anton.ivanov@cambridgegreys.com
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 743f6b973c8ba8a0a5ed15ab11e1d07fa00d5368
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Jun 9 10:04:46 2021 -0400

    NFSv4: Initialise connection to the server in nfs4_alloc_client()
    
    [ Upstream commit dd99e9f98fbf423ff6d365b37a98e8879170f17c ]
    
    Set up the connection to the NFSv4 server in nfs4_alloc_client(), before
    we've added the struct nfs_client to the net-namespace's nfs_client_list
    so that a downed server won't cause other mounts to hang in the trunking
    detection code.
    
    Reported-by: Michael Wakabayashi <mwakabayashi@vmware.com>
    Fixes: 5c6e5b60aae4 ("NFS: Fix an Oops in the pNFS files and flexfiles connection setup to the DS")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit da7680aab76835d2deeee2edc301d0f9a227cc31
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon May 17 12:51:12 2021 +0200

    power: supply: rt5033_battery: Fix device tree enumeration
    
    [ Upstream commit f3076cd8d1d5fa64b5e1fa5affc045c2fc123baa ]
    
    The fuel gauge in the RT5033 PMIC has its own I2C bus and interrupt
    line. Therefore, it is not actually part of the RT5033 MFD and needs
    its own of_match_table to probe properly.
    
    Also, given that it's independent of the MFD, there is actually
    no need to make the Kconfig depend on MFD_RT5033. Although the driver
    uses the shared <linux/mfd/rt5033.h> header, there is no compile
    or runtime dependency on the RT5033 MFD driver.
    
    Cc: Beomho Seo <beomho.seo@samsung.com>
    Cc: Chanwoo Choi <cw00.choi@samsung.com>
    Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b78ad07da08ca15c47af0669d5a4e4f896cbb3c
Author: Krzysztof Wilczyński <kw@linux.com>
Date:   Thu Jun 3 00:01:12 2021 +0000

    PCI/sysfs: Fix dsm_label_utf16s_to_utf8s() buffer overrun
    
    [ Upstream commit bdcdaa13ad96f1a530711c29e6d4b8311eff767c ]
    
    "utf16s_to_utf8s(..., buf, PAGE_SIZE)" puts up to PAGE_SIZE bytes into
    "buf" and returns the number of bytes it actually put there.  If it wrote
    PAGE_SIZE bytes, the newline added by dsm_label_utf16s_to_utf8s() would
    overrun "buf".
    
    Reduce the size available for utf16s_to_utf8s() to use so there is always
    space for the newline.
    
    [bhelgaas: reorder patch in series, commit log]
    Fixes: 6058989bad05 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs")
    Link: https://lore.kernel.org/r/20210603000112.703037-7-kw@linux.com
    Reported-by: Joe Perches <joe@perches.com>
    Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6f8ab706a62e2e2cf3c390b0c46f0bedbb8b1028
Author: Chao Yu <chao@kernel.org>
Date:   Tue May 18 09:57:54 2021 +0800

    f2fs: add MODULE_SOFTDEP to ensure crc32 is included in the initramfs
    
    [ Upstream commit 0dd571785d61528d62cdd8aa49d76bc6085152fe ]
    
    As marcosfrm reported in bugzilla:
    
    https://bugzilla.kernel.org/show_bug.cgi?id=213089
    
    Initramfs generators rely on "pre" softdeps (and "depends") to include
    additional required modules.
    
    F2FS does not declare "pre: crc32" softdep. Then every generator (dracut,
    mkinitcpio...) has to maintain a hardcoded list for this purpose.
    
    Hence let's use MODULE_SOFTDEP("pre: crc32") in f2fs code.
    
    Fixes: 43b6573bac95 ("f2fs: use cryptoapi crc32 functions")
    Reported-by: marcosfrm <marcosfrm@gmail.com>
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5fba782ccd3d12a14f884cd20f255fc9c0eec0c
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Tue May 25 20:56:22 2021 +0800

    virtio_console: Assure used length from device is limited
    
    [ Upstream commit d00d8da5869a2608e97cfede094dfc5e11462a46 ]
    
    The buf->len might come from an untrusted device. This
    ensures the value would not exceed the size of the buffer
    to avoid data corruption or loss.
    
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Link: https://lore.kernel.org/r/20210525125622.1203-1-xieyongji@bytedance.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 845ae8523f5a9ecfdbed48b485cb4ffae71df95b
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Mon May 17 16:45:16 2021 +0800

    virtio_net: Fix error handling in virtnet_restore()
    
    [ Upstream commit 3f2869cace829fb4b80fc53b3ddaa7f4ba9acbf1 ]
    
    Do some cleanups in virtnet_restore() when virtnet_cpu_notif_add() failed.
    
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Link: https://lore.kernel.org/r/20210517084516.332-1-xieyongji@bytedance.com
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 600942d2fd49b90e44857d20c774b20d16f3130f
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Mon May 17 16:43:32 2021 +0800

    virtio-blk: Fix memory leak among suspend/resume procedure
    
    [ Upstream commit b71ba22e7c6c6b279c66f53ee7818709774efa1f ]
    
    The vblk->vqs should be freed before we call init_vqs()
    in virtblk_restore().
    
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Link: https://lore.kernel.org/r/20210517084332.280-1-xieyongji@bytedance.com
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b820a378a2084f50826db3fcfa62102e1dafbbe
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Jun 30 17:23:16 2021 +0200

    ACPI: video: Add quirk for the Dell Vostro 3350
    
    [ Upstream commit 9249c32ec9197e8d34fe5179c9e31668a205db04 ]
    
    The Dell Vostro 3350 ACPI video-bus device reports spurious
    ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE
    events being reported to userspace (and causing trouble there).
    
    Add a quirk setting the report_key_events mask to
    REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE
    events will be ignored, while still reporting brightness up/down
    hotkey-presses to userspace normally.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1911763
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a8a25196a818096f02c187233812c312359c1c9
Author: Liguang Zhang <zhangliguang@linux.alibaba.com>
Date:   Tue Jun 29 19:27:48 2021 +0800

    ACPI: AMBA: Fix resource name in /proc/iomem
    
    [ Upstream commit 7718629432676b5ebd9a32940782fe297a0abf8d ]
    
    In function amba_handler_attach(), dev->res.name is initialized by
    amba_device_alloc. But when address_found is false, dev->res.name is
    assigned to null value, which leads to wrong resource name display in
    /proc/iomem, "<BAD>" is seen for those resources.
    
    Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8c55de0f1995f194eed1ee36c0a6d87c12f97d34
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Thu Jun 17 11:51:41 2021 +0200

    pwm: tegra: Don't modify HW state in .remove callback
    
    [ Upstream commit 86f7fa71cd830d18d7ebcaf719dffd5ddfe1acdd ]
    
    A consumer is expected to disable a PWM before calling pwm_put(). And if
    they didn't there is hopefully a good reason (or the consumer needs
    fixing). Also if disabling an enabled PWM was the right thing to do,
    this should better be done in the framework instead of in each low level
    driver.
    
    So drop the hardware modification from the .remove() callback.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6e4199c16686badb074b1e38355a65c534c2bb6c
Author: Zou Wei <zou_wei@huawei.com>
Date:   Sat Jun 5 09:21:41 2021 +0800

    power: supply: ab8500: add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit dfe52db13ab8d24857a9840ec7ca75eef800c26c ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 87d03711db617565f54e63648fd7713774605529
Author: Zou Wei <zou_wei@huawei.com>
Date:   Sat Jun 5 09:21:54 2021 +0800

    power: supply: charger-manager: add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 073b5d5b1f9cc94a3eea25279fbafee3f4f5f097 ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e409580b19ec7923082e90c1ec9505aa0867f21d
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue May 11 23:41:10 2021 -0400

    NFS: nfs_find_open_context() may only select open files
    
    [ Upstream commit e97bc66377bca097e1f3349ca18ca17f202ff659 ]
    
    If a file has already been closed, then it should not be selected to
    support further I/O.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    [Trond: Fix an invalid pointer deref reported by Colin Ian King]
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 291ddd4e9c5352a4aace1dfb4f3100c743cd87c7
Author: Jeff Layton <jlayton@kernel.org>
Date:   Tue May 4 10:08:30 2021 -0400

    ceph: remove bogus checks and WARN_ONs from ceph_set_page_dirty
    
    [ Upstream commit 22d41cdcd3cfd467a4af074165357fcbea1c37f5 ]
    
    The checks for page->mapping are odd, as set_page_dirty is an
    address_space operation, and I don't see where it would be called on a
    non-pagecache page.
    
    The warning about the page lock also seems bogus.  The comment over
    set_page_dirty() says that it can be called without the page lock in
    some rare cases. I don't think we want to warn if that's the case.
    
    Reported-by: Matthew Wilcox <willy@infradead.org>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0ab6d809cfeffb75c181c29df2235d12b3de844
Author: Mike Marshall <hubcap@omnibond.com>
Date:   Tue May 18 08:09:13 2021 -0400

    orangefs: fix orangefs df output.
    
    [ Upstream commit 0fdec1b3c9fbb5e856a40db5993c9eaf91c74a83 ]
    
    Orangefs df output is whacky. Walt Ligon suggested this might fix it.
    It seems way more in line with reality now...
    
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ef50bb9ea1f1370d2cc1c54184c773a9b0644bc8
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 12:07:02 2021 +0800

    PCI: tegra: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 7bf475a4614a9722b9b989e53184a02596cf16d1 ]
    
    Add missing MODULE_DEVICE_TABLE definition so we generate correct modalias
    for automatic loading of this driver when it is built as a module.
    
    Link: https://lore.kernel.org/r/1620792422-16535-1-git-send-email-zou_wei@huawei.com
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9311a0c9d36caf95555fa2af2e8fc84ec1a81645
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Jun 23 14:02:30 2021 +0200

    x86/fpu: Return proper error codes from user access functions
    
    [ Upstream commit aee8c67a4faa40a8df4e79316dbfc92d123989c1 ]
    
    When *RSTOR from user memory raises an exception, there is no way to
    differentiate them. That's bad because it forces the slow path even when
    the failure was not a fault. If the operation raised eg. #GP then going
    through the slow path is pointless.
    
    Use _ASM_EXTABLE_FAULT() which stores the trap number and let the exception
    fixup return the negated trap number as error.
    
    This allows to separate the fast path and let it handle faults directly and
    avoid the slow path for all other exceptions.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20210623121457.601480369@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5bfbacfeadf864cb23dfe66c610ed036d5e48879
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Sun May 30 13:24:23 2021 +0200

    watchdog: iTCO_wdt: Account for rebooting on second timeout
    
    [ Upstream commit cb011044e34c293e139570ce5c01aed66a34345c ]
    
    This was already attempted to fix via 1fccb73011ea: If the BIOS did not
    enable TCO SMIs, the timer definitely needs to trigger twice in order to
    cause a reboot. If TCO SMIs are on, as well as SMIs in general, we can
    continue to assume that the BIOS will perform a reboot on the first
    timeout.
    
    QEMU with its ICH9 and related BIOS falls into the former category,
    currently taking twice the configured timeout in order to reboot the
    machine. For iTCO version that fall under turn_SMI_watchdog_clear_off,
    this is also true and was currently only addressed for v1, irrespective
    of the turn_SMI_watchdog_clear_off value.
    
    Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/0b8bb307-d08b-41b5-696c-305cdac6789c@siemens.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ecd620e0fb1ff7f78fdb593379b2e6938c99707a
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 14:57:56 2021 +0800

    watchdog: Fix possible use-after-free by calling del_timer_sync()
    
    [ Upstream commit d0212f095ab56672f6f36aabc605bda205e1e0bf ]
    
    This driver's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Acked-by: Vladimir Zapolskiy <vz@mleia.com>
    Link: https://lore.kernel.org/r/1620802676-19701-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 522e75ed63f67e815d4ec0deace67df22d9ce78e
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue May 11 15:04:51 2021 +0800

    watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()
    
    [ Upstream commit 90b7c141132244e8e49a34a4c1e445cce33e07f4 ]
    
    This module's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/1620716691-108460-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc9403097be52d57a5c9c35efa9be79d166a78af
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue May 11 15:01:35 2021 +0800

    watchdog: Fix possible use-after-free in wdt_startup()
    
    [ Upstream commit c08a6b31e4917034f0ed0cb457c3bb209576f542 ]
    
    This module's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/1620716495-108352-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fbc5a04b93788fcb0c05e72a24f170f9c23f3403
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue Jun 1 20:29:26 2021 +0100

    ARM: 9087/1: kprobes: test-thumb: fix for LLVM_IAS=1
    
    [ Upstream commit 8b95a7d90ce8160ac5cffd5bace6e2eba01a871e ]
    
    There's a few instructions that GAS infers operands but Clang doesn't;
    from what I can tell the Arm ARM doesn't say these are optional.
    
    F5.1.257 TBB, TBH T1 Halfword variant
    F5.1.238 STREXD T1 variant
    F5.1.84 LDREXD T1 variant
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1309
    
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Reviewed-by: Jian Cai <jiancai@google.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4c8ea9f317b095b559b73cb148a706c9f483b66f
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Sat May 8 11:14:59 2021 +0800

    power: reset: gpio-poweroff: add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit ed3443fb4df4e140a22f65144546c8a8e1e27f4e ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92dae3d4ba35e86ce36c852a1f2df04b3a4eaff4
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Wed May 26 13:20:35 2021 -0400

    power: supply: max17042: Do not enforce (incorrect) interrupt trigger type
    
    [ Upstream commit 7fbf6b731bca347700e460d94b130f9d734b33e9 ]
    
    Interrupt line can be configured on different hardware in different way,
    even inverted.  Therefore driver should not enforce specific trigger
    type - edge falling - but instead rely on Devicetree to configure it.
    
    The Maxim 17047/77693 datasheets describe the interrupt line as active
    low with a requirement of acknowledge from the CPU therefore the edge
    falling is not correct.
    
    The interrupt line is shared between PMIC and RTC driver, so using level
    sensitive interrupt is here especially important to avoid races.  With
    an edge configuration in case if first PMIC signals interrupt followed
    shortly after by the RTC, the interrupt might not be yet cleared/acked
    thus the second one would not be noticed.
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3c9c6a45e067a5b0eab56ea4882465731f5f6d0e
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sun May 23 00:50:41 2021 +0200

    power: supply: ab8500: Avoid NULL pointers
    
    [ Upstream commit 5bcb5087c9dd3dca1ff0ebd8002c5313c9332b56 ]
    
    Sometimes the code will crash because we haven't enabled
    AC or USB charging and thus not created the corresponding
    psy device. Fix it by checking that it is there before
    notifying.
    
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54913394d67e7aea1e1834640cae284f2658f8b7
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Wed Apr 28 11:05:24 2021 +0200

    pwm: spear: Don't modify HW state in .remove callback
    
    [ Upstream commit b601a18f12383001e7a8da238de7ca1559ebc450 ]
    
    A consumer is expected to disable a PWM before calling pwm_put(). And if
    they didn't there is hopefully a good reason (or the consumer needs
    fixing). Also if disabling an enabled PWM was the right thing to do,
    this should better be done in the framework instead of in each low level
    driver.
    
    So drop the hardware modification from the .remove() callback.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a12a6a2d7cd2dd24663942499f40efab96e8d369
Author: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Date:   Wed Jun 30 18:56:16 2021 -0700

    lib/decompress_unlz4.c: correctly handle zero-padding around initrds.
    
    [ Upstream commit 2c484419efc09e7234c667aa72698cb79ba8d8ed ]
    
    lz4 compatible decompressor is simple.  The format is underspecified and
    relies on EOF notification to determine when to stop.  Initramfs buffer
    format[1] explicitly states that it can have arbitrary number of zero
    padding.  Thus when operating without a fill function, be extra careful to
    ensure that sizes less than 4, or apperantly empty chunksizes are treated
    as EOF.
    
    To test this I have created two cpio initrds, first a normal one,
    main.cpio.  And second one with just a single /test-file with content
    "second" second.cpio.  Then i compressed both of them with gzip, and with
    lz4 -l.  Then I created a padding of 4 bytes (dd if=/dev/zero of=pad4 bs=1
    count=4).  To create four testcase initrds:
    
     1) main.cpio.gzip + extra.cpio.gzip = pad0.gzip
     2) main.cpio.lz4  + extra.cpio.lz4 = pad0.lz4
     3) main.cpio.gzip + pad4 + extra.cpio.gzip = pad4.gzip
     4) main.cpio.lz4  + pad4 + extra.cpio.lz4 = pad4.lz4
    
    The pad4 test-cases replicate the initrd load by grub, as it pads and
    aligns every initrd it loads.
    
    All of the above boot, however /test-file was not accessible in the initrd
    for the testcase #4, as decoding in lz4 decompressor failed.  Also an
    error message printed which usually is harmless.
    
    Whith a patched kernel, all of the above testcases now pass, and
    /test-file is accessible.
    
    This fixes lz4 initrd decompress warning on every boot with grub.  And
    more importantly this fixes inability to load multiple lz4 compressed
    initrds with grub.  This patch has been shipping in Ubuntu kernels since
    January 2021.
    
    [1] ./Documentation/driver-api/early-userspace/buffer-format.rst
    
    BugLink: https://bugs.launchpad.net/bugs/1835660
    Link: https://lore.kernel.org/lkml/20210114200256.196589-1-xnox@ubuntu.com/ # v0
    Link: https://lkml.kernel.org/r/20210513104831.432975-1-dimitri.ledkov@canonical.com
    Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
    Cc: Kyungsik Lee <kyungsik.lee@lge.com>
    Cc: Yinghai Lu <yinghai@kernel.org>
    Cc: Bongkyu Kim <bongkyu.kim@lge.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Sven Schmidt <4sschmid@informatik.uni-hamburg.de>
    Cc: Rajat Asthana <thisisrast7@gmail.com>
    Cc: Nick Terrell <terrelln@fb.com>
    Cc: Gao Xiang <hsiangkao@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c0bb53d48244b10782deea07d57e0a4c0fb4262
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Jun 4 16:27:44 2021 -0700

    i2c: core: Disable client irq on reboot/shutdown
    
    [ Upstream commit b64210f2f7c11c757432ba3701d88241b2b98fb1 ]
    
    If an i2c client receives an interrupt during reboot or shutdown it may
    be too late to service it by making an i2c transaction on the bus
    because the i2c controller has already been shutdown. This can lead to
    system hangs if the i2c controller tries to make a transfer that is
    doomed to fail because the access to the i2c pins is already shut down,
    or an iommu translation has been torn down so i2c controller register
    access doesn't work.
    
    Let's simply disable the irq if there isn't a shutdown callback for an
    i2c client when there is an irq associated with the device. This will
    make sure that irqs don't come in later than the time that we can handle
    it. We don't do this if the i2c client device already has a shutdown
    callback because presumably they're doing the right thing and quieting
    the device so irqs don't come in after the shutdown callback returns.
    
    Reported-by: kernel test robot <lkp@intel.com>
    [swboyd@chromium.org: Dropped newline, added commit text, added
    interrupt.h for robot build error]
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c79fef7357e5930648d7d5991bdfedaca3eb89ad
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Mon Jun 21 18:12:46 2021 +0300

    intel_th: Wait until port is in reset before programming it
    
    [ Upstream commit ab1afed701d2db7eb35c1a2526a29067a38e93d1 ]
    
    Some devices don't drain their pipelines if we don't make sure that
    the corresponding output port is in reset before programming it for
    a new trace capture, resulting in bits of old trace appearing in the
    new trace capture. Fix that by explicitly making sure the reset is
    asserted before programming new trace capture.
    
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Link: https://lore.kernel.org/r/20210621151246.31891-5-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 838f545936c0214b19bc16ba39057c4e6959d89d
Author: Fabio Aiuto <fabioaiuto83@gmail.com>
Date:   Tue Jun 22 15:09:58 2021 +0200

    staging: rtl8723bs: fix macro value for 2.4Ghz only device
    
    [ Upstream commit 6d490a27e23c5fb79b766530016ab8665169498e ]
    
    fix IQK_Matrix_Settings_NUM macro value to 14 which is
    the max channel number value allowed in a 2.4Ghz device.
    
    Acked-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
    Link: https://lore.kernel.org/r/0b4a876929949248aa18cb919da3583c65e4ee4e.1624367072.git.fabioaiuto83@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7970a03e3995e45f01a7dcc090a80f3a7968274
Author: Jiajun Cao <jjcao20@fudan.edu.cn>
Date:   Tue Jun 22 21:19:42 2021 +0800

    ALSA: hda: Add IRQ check for platform_get_irq()
    
    [ Upstream commit 8c13212443230d03ff25014514ec0d53498c0912 ]
    
    The function hda_tegra_first_init() neglects to check the return
    value after executing platform_get_irq().
    
    hda_tegra_first_init() should check the return value (if negative
    error number) for errors so as to not pass a negative value to
    the devm_request_irq().
    
    Fix it by adding a check for the return value irq_id.
    
    Signed-off-by: Jiajun Cao <jjcao20@fudan.edu.cn>
    Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
    Reviewed-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20210622131947.94346-1-jjcao20@fudan.edu.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22ecd1ef4f644881ee75023696d0e442adbe26eb
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Jun 21 14:21:47 2021 +0200

    backlight: lm3630a: Fix return code of .update_status() callback
    
    [ Upstream commit b9481a667a90ec739995e85f91f3672ca44d6ffa ]
    
    According to <linux/backlight.h> .update_status() is supposed to
    return 0 on success and a negative error code otherwise. Adapt
    lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() to
    actually do it.
    
    While touching that also add the error code to the failure message.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b15f3cad6f3637b482701066db3ba31c7af2633e
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Jun 18 13:49:00 2021 +1000

    powerpc/boot: Fixup device-tree on little endian
    
    [ Upstream commit c93f80849bdd9b45d834053ae1336e28f0026c84 ]
    
    This fixes the core devtree.c functions and the ns16550 UART backend.
    
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
    Acked-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/YMwXrPT8nc4YUdJ9@thinks.paulus.ozlabs.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit acf41bb73852e5bcf0bae4033ad72ab671885955
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Jun 18 12:38:35 2021 +0800

    usb: gadget: hid: fix error return code in hid_bind()
    
    [ Upstream commit 88693f770bb09c196b1eb5f06a484a254ecb9924 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210618043835.2641360-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 141fff551c2c0d8f98270d2e3e1c8730e00c24a1
Author: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Date:   Thu Jun 17 19:27:55 2021 +0300

    usb: gadget: f_hid: fix endianness issue with descriptors
    
    [ Upstream commit 33cb46c4676d01956811b68a29157ea969a5df70 ]
    
    Running sparse checker it shows warning message about
    incorrect endianness used for descriptor initialization:
    
    | f_hid.c:91:43: warning: incorrect type in initializer (different base types)
    | f_hid.c:91:43:    expected restricted __le16 [usertype] bcdHID
    | f_hid.c:91:43:    got int
    
    Fixing issue with cpu_to_le16() macro, however this is not a real issue
    as the value is the same both endians.
    
    Cc: Fabien Chouteau <fabien.chouteau@barco.com>
    Cc: Segiy Stetsyuk <serg_stetsuk@ukr.net>
    Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
    Link: https://lore.kernel.org/r/20210617162755.29676-1-ruslan.bilovol@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 903e2d4526c511dc1d324615058b00ce07961cad
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Jun 19 17:39:22 2021 +0900

    ALSA: bebob: add support for ToneWeal FW66
    
    [ Upstream commit 50ebe56222bfa0911a932930f9229ee5995508d9 ]
    
    A user of FFADO project reported the issue of ToneWeal FW66. As a result,
    the device is identified as one of applications of BeBoB solution.
    
    I note that in the report the device returns contradictory result in plug
    discovery process for audio subunit. Fortunately ALSA BeBoB driver doesn't
    perform it thus it's likely to handle the device without issues.
    
    I receive no reaction to test request for this patch yet, however it would
    be worth to add support for it.
    
    daniel@gibbonmoon:/sys/bus/firewire/devices/fw1$ grep -r . *
    Binary file config_rom matches
    dev:244:1
    guid:0x0023270002000000
    hardware_version:0x000002
    is_local:0
    model:0x020002
    model_name:FW66
    power/runtime_active_time:0
    power/runtime_active_kids:0
    power/runtime_usage:0
    power/runtime_status:unsupported
    power/async:disabled
    power/runtime_suspended_time:0
    power/runtime_enabled:disabled
    power/control:auto
    subsystem/drivers_autoprobe:1
    uevent:MAJOR=244
    uevent:MINOR=1
    uevent:DEVNAME=fw1
    units:0x00a02d:0x010001
    vendor:0x002327
    vendor_name:ToneWeal
    fw1.0/uevent:MODALIAS=ieee1394:ven00002327mo00020002sp0000A02Dver00010001
    fw1.0/power/runtime_active_time:0
    fw1.0/power/runtime_active_kids:0
    fw1.0/power/runtime_usage:0
    fw1.0/power/runtime_status:unsupported
    fw1.0/power/async:disabled
    fw1.0/power/runtime_suspended_time:0
    fw1.0/power/runtime_enabled:disabled
    fw1.0/power/control:auto
    fw1.0/model:0x020002
    fw1.0/rom_index:15
    fw1.0/specifier_id:0x00a02d
    fw1.0/model_name:FW66
    fw1.0/version:0x010001
    fw1.0/modalias:ieee1394:ven00002327mo00020002sp0000A02Dver00010001
    
    Cc: Daniel Jozsef <daniel.jozsef@gmail.com>
    Reference: https://lore.kernel.org/alsa-devel/20200119164335.GA11974@workstation/
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20210619083922.16060-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c71a120d34dcda696664c1ee74868f217d4fc4b6
Author: Yizhuo Zhai <yzhai003@ucr.edu>
Date:   Sat Jun 19 22:26:50 2021 -0700

    Input: hideep - fix the uninitialized use in hideep_nvm_unlock()
    
    [ Upstream commit cac7100d4c51c04979dacdfe6c9a5e400d3f0a27 ]
    
    Inside function hideep_nvm_unlock(), variable "unmask_code" could
    be uninitialized if hideep_pgm_r_reg() returns error, however, it
    is used in the later if statement after an "and" operation, which
    is potentially unsafe.
    
    Signed-off-by: Yizhuo <yzhai003@ucr.edu>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b638d66d2980346713f5bc5d4637481520143bc0
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Thu Jun 17 18:37:29 2021 +0800

    ASoC: soc-core: Fix the error return code in snd_soc_of_parse_audio_routing()
    
    [ Upstream commit 7d3865a10b9ff2669c531d5ddd60bf46b3d48f1e ]
    
    When devm_kcalloc() fails, the error code -ENOMEM should be returned
    instead of -EINVAL.
    
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210617103729.1918-1-thunder.leizhen@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b65f7b435e022a74d6777f67b3ae12f960ea26d3
Author: Peter Robinson <pbrobinson@gmail.com>
Date:   Sun Jun 13 23:03:26 2021 +0100

    gpio: pca953x: Add support for the On Semi pca9655
    
    [ Upstream commit 6d49b3a0f351925b5ea5047166c112b7590b918a ]
    
    The On Semi pca9655 is a 16 bit variant of the On Semi pca9654 GPIO
    expander, with 16 GPIOs and interrupt functionality.
    
    Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
    [Bartosz: fixed indentation as noted by Andy]
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1b0912599f13e3bb477853d4d1ae9f8df5566c99
Author: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date:   Tue May 25 09:51:42 2021 -0400

    selftests/powerpc: Fix "no_handler" EBB selftest
    
    [ Upstream commit 45677c9aebe926192e59475b35a1ff35ff2d4217 ]
    
    The "no_handler_test" in ebb selftests attempts to read the PMU
    registers twice via helper function "dump_ebb_state". First dump is
    just before closing of event and the second invocation is done after
    closing of the event. The original intention of second
    dump_ebb_state was to dump the state of registers at the end of
    the test when the counters are frozen. But this will be achieved
    with the first call itself since sample period is set to low value
    and PMU will be frozen by then. Hence patch removes the
    dump which was done before closing of the event.
    
    Reported-by: Shirisha Ganta <shirisha.ganta1@ibm.com>
    Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com <mailto:rnsastry@linux.ibm.com>>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/1621950703-1532-2-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 477448b31d10e6080be66b34f19efb24affad228
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Jun 16 10:11:21 2021 +0800

    ALSA: ppc: fix error return code in snd_pmac_probe()
    
    [ Upstream commit 80b9c1be567c3c6bbe0d4b290af578e630485b5d ]
    
    If snd_pmac_tumbler_init() or snd_pmac_tumbler_post_init() fails,
    snd_pmac_probe() need return error code.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210616021121.1991502-1-yangyingliang@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7a13cbc42793ae74a2dff3fd7f543425830258f
Author: Srinivas Neeli <srinivas.neeli@xilinx.com>
Date:   Fri Apr 9 19:38:05 2021 +0530

    gpio: zynq: Check return value of pm_runtime_get_sync
    
    [ Upstream commit a51b2fb94b04ab71e53a71b9fad03fa826941254 ]
    
    Return value of "pm_runtime_get_sync" API was neither captured nor checked.
    Fixed it by capturing the return value and then checking for any warning.
    
    Addresses-Coverity: "check_return"
    Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com>
    Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c58022e95bd62435cb05a3a61c24905e3aa6280c
Author: Geoff Levand <geoff@infradead.org>
Date:   Thu Jun 3 19:17:02 2021 +0000

    powerpc/ps3: Add dma_mask to ps3_dma_region
    
    [ Upstream commit 9733862e50fdba55e7f1554e4286fcc5302ff28e ]
    
    Commit f959dcd6ddfd29235030e8026471ac1b022ad2b0 (dma-direct: Fix
    potential NULL pointer dereference) added a null check on the
    dma_mask pointer of the kernel's device structure.
    
    Add a dma_mask variable to the ps3_dma_region structure and set
    the device structure's dma_mask pointer to point to this new variable.
    
    Fixes runtime errors like these:
    # WARNING: Fixes tag on line 10 doesn't match correct format
    # WARNING: Fixes tag on line 10 doesn't match correct format
    
      ps3_system_bus_match:349: dev=8.0(sb_01), drv=8.0(ps3flash): match
      WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:151 .dma_map_page_attrs+0x34/0x1e0
      ps3flash sb_01: ps3stor_setup:193: map DMA region failed
    
    Signed-off-by: Geoff Levand <geoff@infradead.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/562d0c9ea0100a30c3b186bcc7adb34b0bbd2cd7.1622746428.git.geoff@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9ec6184908c650f261eb09fdb18a513150ea1ce7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jun 8 16:04:37 2021 +0200

    ALSA: sb: Fix potential double-free of CSP mixer elements
    
    [ Upstream commit c305366a37441c2ac90b08711cb6f032b43672f2 ]
    
    snd_sb_qsound_destroy() contains the calls of removing the previously
    created mixer controls, but it doesn't clear the pointers.  As
    snd_sb_qsound_destroy() itself may be repeatedly called via ioctl,
    this could lead to double-free potentially.
    
    Fix it by clearing the struct fields properly afterwards.
    
    Link: https://lore.kernel.org/r/20210608140540.17885-4-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e4bb007af559066d8f93dc63c9d137b03372b81e
Author: Po-Hsu Lin <po-hsu.lin@canonical.com>
Date:   Tue May 25 10:36:14 2021 +0800

    selftests: timers: rtcpie: skip test if default RTC device does not exist
    
    [ Upstream commit 0d3e5a057992bdc66e4dca2ca50b77fa4a7bd90e ]
    
    This test will require /dev/rtc0, the default RTC device, or one
    specified by user to run. Since this default RTC is not guaranteed to
    exist on all of the devices, so check its existence first, otherwise
    skip this test with the kselftest skip code 4.
    
    Without this patch this test will fail like this on a s390x zVM:
    $ selftests: timers: rtcpie
    $ /dev/rtc0: No such file or directory
    not ok 1 selftests: timers: rtcpie # exit=22
    
    With this patch:
    $ selftests: timers: rtcpie
    $ Default RTC /dev/rtc0 does not exist. Test Skipped!
    not ok 9 selftests: timers: rtcpie # SKIP
    
    Fixed up change log so "With this patch" text doesn't get dropped.
    Shuah Khan <skhan@linuxfoundation.org>
    
    Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2936c01a51cf344e2b17cbd66ded8b809976667
Author: Valentin Vidic <vvidic@valentin-vidic.from.hr>
Date:   Tue Apr 27 21:40:10 2021 +0200

    s390/sclp_vt220: fix console name to match device
    
    [ Upstream commit b7d91d230a119fdcc334d10c9889ce9c5e15118b ]
    
    Console name reported in /proc/consoles:
    
      ttyS1                -W- (EC p  )    4:65
    
    does not match the char device name:
    
      crw--w----    1 root     root        4,  65 May 17 12:18 /dev/ttysclp0
    
    so debian-installer inside a QEMU s390x instance gets confused and fails
    to start with the following error:
    
      steal-ctty: No such file or directory
    
    Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr>
    Link: https://lore.kernel.org/r/20210427194010.9330-1-vvidic@valentin-vidic.from.hr
    Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2296b9c244cdd93cbb28c3e48e33be45447d11f3
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 14:33:46 2021 +0800

    mfd: da9052/stmpe: Add and modify MODULE_DEVICE_TABLE
    
    [ Upstream commit 4700ef326556ed74aba188f12396740a8c1c21dd ]
    
    This patch adds/modifies MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 545de233de7d8ae2655d679d9e2a9e22497629f1
Author: Mike Christie <michael.christie@oracle.com>
Date:   Tue May 25 13:18:12 2021 -0500

    scsi: qedi: Fix null ref during abort handling
    
    [ Upstream commit 5777b7f0f03ce49372203b6521631f62f2810c8f ]
    
    If qedi_process_cmd_cleanup_resp finds the cmd it frees the work and sets
    list_tmf_work to NULL, so qedi_tmf_work should check if list_tmf_work is
    non-NULL when it wants to force cleanup.
    
    Link: https://lore.kernel.org/r/20210525181821.7617-20-michael.christie@oracle.com
    Reviewed-by: Manish Rangankar <mrangankar@marvell.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 693e09c3be3cc130320036861c0d249da03bf1be
Author: Mike Christie <michael.christie@oracle.com>
Date:   Tue May 25 13:18:07 2021 -0500

    scsi: iscsi: Fix shost->max_id use
    
    [ Upstream commit bdd4aad7ff92ae39c2e93c415bb6761cb8b584da ]
    
    The iscsi offload drivers are setting the shost->max_id to the max number
    of sessions they support. The problem is that max_id is not the max number
    of targets but the highest identifier the targets can have. To use it to
    limit the number of targets we need to set it to max sessions - 1, or we
    can end up with a session we might not have preallocated resources for.
    
    Link: https://lore.kernel.org/r/20210525181821.7617-15-michael.christie@oracle.com
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf20d85a88384574fabb3d53ad62a8af57e7ab11
Author: Mike Christie <michael.christie@oracle.com>
Date:   Tue May 25 13:18:06 2021 -0500

    scsi: iscsi: Fix conn use after free during resets
    
    [ Upstream commit ec29d0ac29be366450a7faffbcf8cba3a6a3b506 ]
    
    If we haven't done a unbind target call we can race where
    iscsi_conn_teardown wakes up the EH thread and then frees the conn while
    those threads are still accessing the conn ehwait.
    
    We can only do one TMF per session so this just moves the TMF fields from
    the conn to the session. We can then rely on the
    iscsi_session_teardown->iscsi_remove_session->__iscsi_unbind_session call
    to remove the target and it's devices, and know after that point there is
    no device or scsi-ml callout trying to access the session.
    
    Link: https://lore.kernel.org/r/20210525181821.7617-14-michael.christie@oracle.com
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d3f5e3b4ebe1e4cdc9f6d79dd24e77aa8007efb
Author: Mike Christie <michael.christie@oracle.com>
Date:   Tue May 25 13:18:03 2021 -0500

    scsi: iscsi: Add iscsi_cls_conn refcount helpers
    
    [ Upstream commit b1d19e8c92cfb0ded180ef3376c20e130414e067 ]
    
    There are a couple places where we could free the iscsi_cls_conn while it's
    still in use. This adds some helpers to get/put a refcount on the struct
    and converts an exiting user. Subsequent commits will then use the helpers
    to fix 2 bugs in the eh code.
    
    Link: https://lore.kernel.org/r/20210525181821.7617-11-michael.christie@oracle.com
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8a63ff46c2196bb9cd2a7afbfe7aa4cb3388f5b8
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Tue Jun 1 19:07:10 2021 +0800

    fs/jfs: Fix missing error code in lmLogInit()
    
    [ Upstream commit 492109333c29e1bb16d8732e1d597b02e8e0bf2e ]
    
    The error code is missing in this code scenario, add the error code
    '-EINVAL' to the return value 'rc.
    
    Eliminate the follow smatch warning:
    
    fs/jfs/jfs_logmgr.c:1327 lmLogInit() warn: missing error code 'rc'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f4bde1d1bf905590c55acb02104c60d1c281a24f
Author: Hannes Reinecke <hare@suse.de>
Date:   Tue Apr 27 10:30:11 2021 +0200

    scsi: scsi_dh_alua: Check for negative result value
    
    [ Upstream commit 7e26e3ea028740f934477ec01ba586ab033c35aa ]
    
    scsi_execute() will now return a negative error if there was an error prior
    to command submission; evaluate that instead if checking for DRIVER_ERROR.
    
    [mkp: build fix]
    
    Link: https://lore.kernel.org/r/20210427083046.31620-6-hare@suse.de
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cddee5c287e26f6b2ba5c0ffdfc3a846f2f10461
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue May 25 21:44:04 2021 +0200

    tty: serial: 8250: serial_cs: Fix a memory leak in error handling path
    
    [ Upstream commit fad92b11047a748c996ebd6cfb164a63814eeb2e ]
    
    In the probe function, if the final 'serial_config()' fails, 'info' is
    leaking.
    
    Add a resource handling path to free this memory.
    
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/dc25f96b7faebf42e60fe8d02963c941cf4d8124.1621971720.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c3a170279bf2cd870d30a97344e91db5dccf1d2
Author: Yufen Yu <yuyufen@huawei.com>
Date:   Mon May 24 05:38:11 2021 -0400

    ALSA: ac97: fix PM reference leak in ac97_bus_remove()
    
    [ Upstream commit a38e93302ee25b2ca6f4ee76c6c974cf3637985e ]
    
    pm_runtime_get_sync will increment pm usage counter even it failed.
    Forgetting to putting operation will result in reference leak here.
    Fix it by replacing it with pm_runtime_resume_and_get to keep usage
    counter balanced.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yufen Yu <yuyufen@huawei.com>
    Link: https://lore.kernel.org/r/20210524093811.612302-1-yuyufen@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 029028f4e90be206950c31fb2adadcbb1f0b32c0
Author: John Garry <john.garry@huawei.com>
Date:   Wed May 19 22:31:02 2021 +0800

    scsi: core: Cap scsi_host cmd_per_lun at can_queue
    
    [ Upstream commit ea2f0f77538c50739b9fb4de4700cee5535e1f77 ]
    
    The sysfs handling function sdev_store_queue_depth() enforces that the sdev
    queue depth cannot exceed shost can_queue. The initial sdev queue depth
    comes from shost cmd_per_lun. However, the LLDD may manually set
    cmd_per_lun to be larger than can_queue, which leads to an initial sdev
    queue depth greater than can_queue.
    
    Such an issue was reported in [0], which caused a hang. That has since been
    fixed in commit fc09acb7de31 ("scsi: scsi_debug: Fix cmd_per_lun, set to
    max_queue").
    
    Stop this possibly happening for other drivers by capping shost cmd_per_lun
    at shost can_queue.
    
    [0] https://lore.kernel.org/linux-scsi/YHaez6iN2HHYxYOh@T590/
    
    Link: https://lore.kernel.org/r/1621434662-173079-1-git-send-email-john.garry@huawei.com
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7813fa911ca35df50fe792a49d4579afb83d0fcb
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri May 14 12:55:56 2021 -0700

    scsi: lpfc: Fix crash when lpfc_sli4_hba_setup() fails to initialize the SGLs
    
    [ Upstream commit 5aa615d195f1e142c662cb2253f057c9baec7531 ]
    
    The driver is encountering a crash in lpfc_free_iocb_list() while
    performing initial attachment.
    
    Code review found this to be an errant failure path that was taken, jumping
    to a tag that then referenced structures that were uninitialized.
    
    Fix the failure path.
    
    Link: https://lore.kernel.org/r/20210514195559.119853-9-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ec9999dc550eb263a1a782ae31aaf7c7b59716cf
Author: James Smart <jsmart2021@gmail.com>
Date:   Fri May 14 12:55:51 2021 -0700

    scsi: lpfc: Fix "Unexpected timeout" error in direct attach topology
    
    [ Upstream commit e30d55137edef47434c40d7570276a0846fe922c ]
    
    An 'unexpected timeout' message may be seen in a point-2-point topology.
    The message occurs when a PLOGI is received before the driver is notified
    of FLOGI completion. The FLOGI completion failure causes discovery to be
    triggered for a second time. The discovery timer is restarted but no new
    discovery activity is initiated, thus the timeout message eventually
    appears.
    
    In point-2-point, when discovery has progressed before the FLOGI completion
    is processed, it is not a failure. Add code to FLOGI completion to detect
    that discovery has progressed and exit the FLOGI handling (noop'ing it).
    
    Link: https://lore.kernel.org/r/20210514195559.119853-4-jsmart2021@gmail.com
    Co-developed-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Signed-off-by: James Smart <jsmart2021@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 36164ba715d8325124789d3ce9e8bafd52856412
Author: Luiz Sampaio <sampaio.ime@gmail.com>
Date:   Wed May 19 19:30:44 2021 -0300

    w1: ds2438: fixing bug that would always get page0
    
    [ Upstream commit 1f5e7518f063728aee0679c5086b92d8ea429e11 ]
    
    The purpose of the w1_ds2438_get_page function is to get the register
    values at the page passed as the pageno parameter. However, the page0 was
    hardcoded, such that the function always returned the page0 contents. Fixed
    so that the function can retrieve any page.
    
    Signed-off-by: Luiz Sampaio <sampaio.ime@gmail.com>
    Link: https://lore.kernel.org/r/20210519223046.13798-5-sampaio.ime@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1a89fdc49f8729be08e86a225598a36a9a6d5cff
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Tue May 18 17:45:47 2021 +0900

    Revert "ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro"
    
    [ Upstream commit 5d6fb80a142b5994355ce675c517baba6089d199 ]
    
    This reverts commit 0edabdfe89581669609eaac5f6a8d0ae6fe95e7f.
    
    I've explained that optional FireWire card for d.2 is also built-in to
    d.2 Pro, however it's wrong. The optional card uses DM1000 ASIC and has
    'Mackie DJ Mixer' in its model name of configuration ROM. On the other
    hand, built-in FireWire card for d.2 Pro and d.4 Pro uses OXFW971 ASIC
    and has 'd.Pro' in its model name according to manuals and user
    experiences. The former card is not the card for d.2 Pro. They are similar
    in appearance but different internally.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://lore.kernel.org/r/20210518084557.102681-2-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 481a76d4749ee3a27f902ba213fdcbb4bb39720e
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Mon Apr 26 10:06:20 2021 -0700

    misc/libmasm/module: Fix two use after free in ibmasm_init_one
    
    [ Upstream commit 7272b591c4cb9327c43443f67b8fbae7657dd9ae ]
    
    In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().
    Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are
    allocated by input_allocate_device(), and assigned to
    sp->remote.mouse_dev and sp->remote.keybd_dev respectively.
    
    In the err_free_devices error branch of ibmasm_init_one,
    mouse_dev and keybd_dev are freed by input_free_device(), and return
    error. Then the execution runs into error_send_message error branch
    of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called
    to unregister the freed sp->remote.mouse_dev and sp->remote.keybd_dev.
    
    My patch add a "error_init_remote" label to handle the error of
    ibmasm_init_remote_input_dev(), to avoid the uaf bugs.
    
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Link: https://lore.kernel.org/r/20210426170620.10546-1-lyl2019@mail.ustc.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d8421902085c0c373146417088f5ee6a15ad70a
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Tue Apr 27 10:12:26 2021 +0800

    tty: serial: fsl_lpuart: fix the potential risk of division or modulo by zero
    
    [ Upstream commit fcb10ee27fb91b25b68d7745db9817ecea9f1038 ]
    
    We should be very careful about the register values that will be used
    for division or modulo operations, althrough the possibility that the
    UARTBAUD register value is zero is very low, but we had better to deal
    with the "bad data" of hardware in advance to avoid division or modulo
    by zero leading to undefined kernel behavior.
    
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Link: https://lore.kernel.org/r/20210427021226.27468-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b00a9aaa4be20ad6e3311fb78a485eae0899e89a
Author: Pali Rohár <pali@kernel.org>
Date:   Tue Jun 8 22:36:55 2021 +0200

    PCI: aardvark: Fix kernel panic during PIO transfer
    
    commit f18139966d072dab8e4398c95ce955a9742e04f7 upstream.
    
    Trying to start a new PIO transfer by writing value 0 in PIO_START register
    when previous transfer has not yet completed (which is indicated by value 1
    in PIO_START) causes an External Abort on CPU, which results in kernel
    panic:
    
        SError Interrupt on CPU0, code 0xbf000002 -- SError
        Kernel panic - not syncing: Asynchronous SError Interrupt
    
    To prevent kernel panic, it is required to reject a new PIO transfer when
    previous one has not finished yet.
    
    If previous PIO transfer is not finished yet, the kernel may issue a new
    PIO request only if the previous PIO transfer timed out.
    
    In the past the root cause of this issue was incorrectly identified (as it
    often happens during link retraining or after link down event) and special
    hack was implemented in Trusted Firmware to catch all SError events in EL3,
    to ignore errors with code 0xbf000002 and not forwarding any other errors
    to kernel and instead throw panic from EL3 Trusted Firmware handler.
    
    Links to discussion and patches about this issue:
    https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
    https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
    https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
    https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
    
    But the real cause was the fact that during link retraining or after link
    down event the PIO transfer may take longer time, up to the 1.44s until it
    times out. This increased probability that a new PIO transfer would be
    issued by kernel while previous one has not finished yet.
    
    After applying this change into the kernel, it is possible to revert the
    mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.
    
    Link: https://lore.kernel.org/r/20210608203655.31228-1-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6571c80330ac43f2487403f04efcdbbcf796cf7b
Author: Remi Pommarel <repk@triplefau.lt>
Date:   Fri Sep 27 10:55:02 2019 +0200

    PCI: aardvark: Don't rely on jiffies while holding spinlock
    
    commit 7fbcb5da811be7d47468417c7795405058abb3da upstream.
    
    advk_pcie_wait_pio() can be called while holding a spinlock (from
    pci_bus_read_config_dword()), then depends on jiffies in order to
    timeout while polling on PIO state registers. In the case the PIO
    transaction failed, the timeout will never happen and will also cause
    the cpu to stall.
    
    This decrements a variable and wait instead of using jiffies.
    
    Signed-off-by: Remi Pommarel <repk@triplefau.lt>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Andrew Murray <andrew.murray@arm.com>
    Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1834fbbd664ca9aa51258c617bc8aa0206cd28b6
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Jul 15 00:02:06 2021 -0400

    tracing: Do not reference char * as a string in histograms
    
    commit 704adfb5a9978462cd861f170201ae2b5e3d3a80 upstream.
    
    The histogram logic was allowing events with char * pointers to be used as
    normal strings. But it was easy to crash the kernel with:
    
     # echo 'hist:keys=filename' > events/syscalls/sys_enter_openat/trigger
    
    And open some files, and boom!
    
     BUG: unable to handle page fault for address: 00007f2ced0c3280
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 1173fa067 P4D 1173fa067 PUD 1171b6067 PMD 1171dd067 PTE 0
     Oops: 0000 [#1] PREEMPT SMP
     CPU: 6 PID: 1810 Comm: cat Not tainted 5.13.0-rc5-test+ #61
     Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01
    v03.03 07/14/2016
     RIP: 0010:strlen+0x0/0x20
     Code: f6 82 80 2a 0b a9 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2a 0b
    a9 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74
    10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3
    
     RSP: 0018:ffffbdbf81567b50 EFLAGS: 00010246
     RAX: 0000000000000003 RBX: ffff93815cdb3800 RCX: ffff9382401a22d0
     RDX: 0000000000000100 RSI: 0000000000000000 RDI: 00007f2ced0c3280
     RBP: 0000000000000100 R08: ffff9382409ff074 R09: ffffbdbf81567c98
     R10: ffff9382409ff074 R11: 0000000000000000 R12: ffff9382409ff074
     R13: 0000000000000001 R14: ffff93815a744f00 R15: 00007f2ced0c3280
     FS:  00007f2ced0f8580(0000) GS:ffff93825a800000(0000)
    knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007f2ced0c3280 CR3: 0000000107069005 CR4: 00000000001706e0
     Call Trace:
      event_hist_trigger+0x463/0x5f0
      ? find_held_lock+0x32/0x90
      ? sched_clock_cpu+0xe/0xd0
      ? lock_release+0x155/0x440
      ? kernel_init_free_pages+0x6d/0x90
      ? preempt_count_sub+0x9b/0xd0
      ? kernel_init_free_pages+0x6d/0x90
      ? get_page_from_freelist+0x12c4/0x1680
      ? __rb_reserve_next+0xe5/0x460
      ? ring_buffer_lock_reserve+0x12a/0x3f0
      event_triggers_call+0x52/0xe0
      ftrace_syscall_enter+0x264/0x2c0
      syscall_trace_enter.constprop.0+0x1ee/0x210
      do_syscall_64+0x1c/0x80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Where it triggered a fault on strlen(key) where key was the filename.
    
    The reason is that filename is a char * to user space, and the histogram
    code just blindly dereferenced it, with obvious bad results.
    
    I originally tried to use strncpy_from_user/kernel_nofault() but found
    that there's other places that its dereferenced and not worth the effort.
    
    Just do not allow "char *" to act like strings.
    
    Link: https://lkml.kernel.org/r/20210715000206.025df9d2@rorschach.local.home
    
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
    Cc: stable@vger.kernel.org
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Acked-by: Tom Zanussi <zanussi@kernel.org>
    Fixes: 79e577cbce4c4 ("tracing: Support string type key properly")
    Fixes: 5967bd5c4239 ("tracing: Let filter_assign_type() detect FILTER_PTR_STRING")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1bd3fac2baa3d5c04375980c1d5263a3335af92
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
Date:   Thu Jul 1 13:56:59 2021 -0600

    scsi: core: Fix bad pointer dereference when ehandler kthread is invalid
    
    commit 93aa71ad7379900e61c8adff6a710a4c18c7c99b upstream.
    
    Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
    changed the allocation logic to call put_device() to perform host cleanup
    with the assumption that IDA removal and stopping the kthread would
    properly be performed in scsi_host_dev_release(). However, in the unlikely
    case that the error handler thread fails to spawn, shost->ehandler is set
    to ERR_PTR(-ENOMEM).
    
    The error handler cleanup code in scsi_host_dev_release() will call
    kthread_stop() if shost->ehandler != NULL which will always be the case
    whether the kthread was successfully spawned or not. In the case that it
    failed to spawn this has the nasty side effect of trying to dereference an
    invalid pointer when kthread_stop() is called. The following splat provides
    an example of this behavior in the wild:
    
    scsi host11: error handler thread failed to spawn, error = -4
    Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)
    BUG: Kernel NULL pointer dereference on read at 0x0000010c
    Faulting instruction address: 0xc00000000818e9a8
    Oops: Kernel access of bad area, sig: 11 [#1]
    LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
    Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region
     hash dm_log dm_mod fuse overlay squashfs loop
    CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1
    NIP:  c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8
    REGS: c000000037d12ea0 TRAP: 0300   Not tainted  (5.13.0-rc7)
    MSR:  800000000280b033 &lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 28228228
    XER: 20040001
    CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0
    GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc
    GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000
    GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff
    GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0
    GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288
    GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898
    GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000
    GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc
    NIP [c00000000818e9a8] kthread_stop+0x38/0x230
    LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160
    Call Trace:
    [c000000033bb2c48] 0xc000000033bb2c48 (unreliable)
    [c0000000089846e8] scsi_host_dev_release+0x98/0x160
    [c00000000891e960] device_release+0x60/0x100
    [c0000000087e55c4] kobject_release+0x84/0x210
    [c00000000891ec78] put_device+0x28/0x40
    [c000000008984ea4] scsi_host_alloc+0x314/0x430
    [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]
    [c000000008110104] vio_bus_probe+0xa4/0x4b0
    [c00000000892a860] really_probe+0x140/0x680
    [c00000000892aefc] driver_probe_device+0x15c/0x200
    [c00000000892b63c] device_driver_attach+0xcc/0xe0
    [c00000000892b740] __driver_attach+0xf0/0x200
    [c000000008926f28] bus_for_each_dev+0xa8/0x130
    [c000000008929ce4] driver_attach+0x34/0x50
    [c000000008928fc0] bus_add_driver+0x1b0/0x300
    [c00000000892c798] driver_register+0x98/0x1a0
    [c00000000810eb60] __vio_register_driver+0x80/0xe0
    [c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]
    [c0000000080121d0] do_one_initcall+0x60/0x2d0
    [c000000008261abc] do_init_module+0x7c/0x320
    [c000000008265700] load_module+0x2350/0x25b0
    [c000000008265cb4] __do_sys_finit_module+0xd4/0x160
    [c000000008031110] system_call_exception+0x150/0x2d0
    [c00000000800d35c] system_call_common+0xec/0x278
    
    Fix this be nulling shost->ehandler when the kthread fails to spawn.
    
    Link: https://lore.kernel.org/r/20210701195659.3185475-1-tyreld@linux.ibm.com
    Fixes: 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
    Cc: stable@vger.kernel.org
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e6d27d667571831fdb88cfc09b277951f06aa37
Author: Lai Jiangshan <laijs@linux.alibaba.com>
Date:   Tue Jun 29 01:26:32 2021 +0800

    KVM: X86: Disable hardware breakpoints unconditionally before kvm_x86->run()
    
    commit f85d40160691881a17a397c448d799dfc90987ba upstream.
    
    When the host is using debug registers but the guest is not using them
    nor is the guest in guest-debug state, the kvm code does not reset
    the host debug registers before kvm_x86->run().  Rather, it relies on
    the hardware vmentry instruction to automatically reset the dr7 registers
    which ensures that the host breakpoints do not affect the guest.
    
    This however violates the non-instrumentable nature around VM entry
    and exit; for example, when a host breakpoint is set on vcpu->arch.cr2,
    
    Another issue is consistency.  When the guest debug registers are active,
    the host breakpoints are reset before kvm_x86->run(). But when the
    guest debug registers are inactive, the host breakpoints are delayed to
    be disabled.  The host tracing tools may see different results depending
    on what the guest is doing.
    
    To fix the problems, we clear %db7 unconditionally before kvm_x86->run()
    if the host has set any breakpoints, no matter if the guest is using
    them or not.
    
    Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
    Message-Id: <20210628172632.81029-1-jiangshanlai@gmail.com>
    Cc: stable@vger.kernel.org
    [Only clear %db7 instead of reloading all debug registers. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit af9045cf57680ea38af578d333e6fc466e656996
Author: Sean Christopherson <seanjc@google.com>
Date:   Wed Jun 23 16:05:46 2021 -0700

    KVM: x86: Use guest MAXPHYADDR from CPUID.0x8000_0008 iff TDP is enabled
    
    commit 4bf48e3c0aafd32b960d341c4925b48f416f14a5 upstream.
    
    Ignore the guest MAXPHYADDR reported by CPUID.0x8000_0008 if TDP, i.e.
    NPT, is disabled, and instead use the host's MAXPHYADDR.  Per AMD'S APM:
    
      Maximum guest physical address size in bits. This number applies only
      to guests using nested paging. When this field is zero, refer to the
      PhysAddrSize field for the maximum guest physical address size.
    
    Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20210623230552.4027702-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cbd87ba6a13891acf6180783f8234a8b7a3e3d4d
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Mon Apr 12 22:45:50 2021 +0900

    smackfs: restrict bytes count in smk_set_cipso()
    
    commit 49ec114a6e62d8d320037ce71c1aaf9650b3cafd upstream.
    
    Oops, I failed to update subject line.
    
    From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001
    From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Date: Mon, 12 Apr 2021 22:25:06 +0900
    Subject: smackfs: restrict bytes count in smk_set_cipso()
    
    Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write
    functions") missed that count > SMK_CIPSOMAX check applies to only
    format == SMK_FIXED24_FMT case.
    
    Reported-by: syzbot <syzbot+77c53db50c9fff774e8e@syzkaller.appspotmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aff8d95b69051d0cf4acc3d91f22299fdbb9dfb3
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Sun Jun 6 17:24:05 2021 +0300

    jfs: fix GPF in diFree
    
    commit 9d574f985fe33efd6911f4d752de6f485a1ea732 upstream.
    
    Avoid passing inode with
    JFS_SBI(inode->i_sb)->ipimap == NULL to
    diFree()[1]. GFP will appear:
    
            struct inode *ipimap = JFS_SBI(ip->i_sb)->ipimap;
            struct inomap *imap = JFS_IP(ipimap)->i_imap;
    
    JFS_IP() will return invalid pointer when ipimap == NULL
    
    Call Trace:
     diFree+0x13d/0x2dc0 fs/jfs/jfs_imap.c:853 [1]
     jfs_evict_inode+0x2c9/0x370 fs/jfs/inode.c:154
     evict+0x2ed/0x750 fs/inode.c:578
     iput_final fs/inode.c:1654 [inline]
     iput.part.0+0x3fe/0x820 fs/inode.c:1680
     iput+0x58/0x70 fs/inode.c:1670
    
    Reported-and-tested-by: syzbot+0a89a7b56db04c21a656@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c592ce0bced05b54c088da30dd0d50b6598eb86f
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue Jun 8 14:34:08 2021 +0800

    pinctrl: mcp23s08: Fix missing unlock on error in mcp23s08_irq()
    
    commit 884af72c90016cfccd5717439c86b48702cbf184 upstream.
    
    Add the missing unlock before return from function mcp23s08_irq()
    in the error handling case.
    
    v1-->v2:
       remove the "return IRQ_HANDLED" line
    
    Fixes: 897120d41e7a ("pinctrl: mcp23s08: fix race condition in irq handler")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Link: https://lore.kernel.org/r/1623134048-56051-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 324626f594fdd1d94c0a7919e2808866477c11b8
Author: Benjamin Drung <bdrung@posteo.de>
Date:   Sat Jun 5 22:15:36 2021 +0200

    media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K
    
    commit 4c6e0976295add7f0ed94d276c04a3d6f1ea8f83 upstream.
    
    The Elgato Cam Link 4K HDMI video capture card reports to support three
    different pixel formats, where the first format depends on the connected
    HDMI device.
    
    ```
    $ v4l2-ctl -d /dev/video0 --list-formats-ext
    ioctl: VIDIOC_ENUM_FMT
            Type: Video Capture
    
            [0]: 'NV12' (Y/CbCr 4:2:0)
                    Size: Discrete 3840x2160
                            Interval: Discrete 0.033s (29.970 fps)
            [1]: 'NV12' (Y/CbCr 4:2:0)
                    Size: Discrete 3840x2160
                            Interval: Discrete 0.033s (29.970 fps)
            [2]: 'YU12' (Planar YUV 4:2:0)
                    Size: Discrete 3840x2160
                            Interval: Discrete 0.033s (29.970 fps)
    ```
    
    Changing the pixel format to anything besides the first pixel format
    does not work:
    
    ```
    $ v4l2-ctl -d /dev/video0 --try-fmt-video pixelformat=YU12
    Format Video Capture:
            Width/Height      : 3840/2160
            Pixel Format      : 'NV12' (Y/CbCr 4:2:0)
            Field             : None
            Bytes per Line    : 3840
            Size Image        : 12441600
            Colorspace        : sRGB
            Transfer Function : Rec. 709
            YCbCr/HSV Encoding: Rec. 709
            Quantization      : Default (maps to Limited Range)
            Flags             :
    ```
    
    User space applications like VLC might show an error message on the
    terminal in that case:
    
    ```
    libv4l2: error set_fmt gave us a different result than try_fmt!
    ```
    
    Depending on the error handling of the user space applications, they
    might display a distorted video, because they use the wrong pixel format
    for decoding the stream.
    
    The Elgato Cam Link 4K responds to the USB video probe
    VS_PROBE_CONTROL/VS_COMMIT_CONTROL with a malformed data structure: The
    second byte contains bFormatIndex (instead of being the second byte of
    bmHint). The first byte is always zero. The third byte is always 1.
    
    The firmware bug was reported to Elgato on 2020-12-01 and it was
    forwarded by the support team to the developers as feature request.
    There is no firmware update available since then. The latest firmware
    for Elgato Cam Link 4K as of 2021-03-23 has MCU 20.02.19 and FPGA 67.
    
    Therefore correct the malformed data structure for this device. The
    change was successfully tested with VLC, OBS, and Chromium using
    different pixel formats (YUYV, NV12, YU12), resolutions (3840x2160,
    1920x1080), and frame rates (29.970 and 59.940 fps).
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Benjamin Drung <bdrung@posteo.de>
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a181ec5fcf6cdcff54cd1e3013d6394c6d888b7
Author: Johan Hovold <johan@kernel.org>
Date:   Mon May 24 13:09:19 2021 +0200

    media: gspca/sunplus: fix zero-length control requests
    
    commit b4bb4d425b7b02424afea2dfdcd77b3b4794175e upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Control transfers without a data stage are treated as OUT requests by
    the USB stack and should be using usb_sndctrlpipe(). Failing to do so
    will now trigger a warning.
    
    Fix the single zero-length control request which was using the
    read-register helper, and update the helper so that zero-length reads
    fail with an error message instead.
    
    Fixes: 6a7eba24e4f0 ("V4L/DVB (8157): gspca: all subdrivers")
    Cc: stable@vger.kernel.org      # 2.6.27
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4ddc5afe922790d3c4a156abefb235e08b5f4393
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 21 15:28:39 2021 +0200

    media: gspca/sq905: fix control-request direction
    
    commit 53ae298fde7adcc4b1432bce2dbdf8dac54dfa72 upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the USB_REQ_SYNCH_FRAME request which erroneously used
    usb_sndctrlpipe().
    
    Fixes: 27d35fc3fb06 ("V4L/DVB (10639): gspca - sq905: New subdriver.")
    Cc: stable@vger.kernel.org      # 2.6.30
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 021c294dff030f3ba38eb81e400ba123db32ecbc
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon May 17 21:18:14 2021 +0200

    media: zr364xx: fix memory leak in zr364xx_start_readpipe
    
    commit 0a045eac8d0427b64577a24d74bb8347c905ac65 upstream.
    
    syzbot reported memory leak in zr364xx driver.
    The problem was in non-freed urb in case of
    usb_submit_urb() fail.
    
    backtrace:
      [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline]
      [<ffffffff82baedf6>] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
      [<ffffffff82f7cce8>] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022
      [<ffffffff84251dfc>] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]
      [<ffffffff84251dfc>] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516
      [<ffffffff82bb6507>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
      [<ffffffff826018a9>] really_probe+0x159/0x500 drivers/base/dd.c:576
    
    Fixes: ccbf035ae5de ("V4L/DVB (12278): zr364xx: implement V4L2_CAP_STREAMING")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+af4fa391ef18efdd5f69@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17dc6ca47864362a5c7be163024aae112a7e4913
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 21 15:28:38 2021 +0200

    media: dtv5100: fix control-request directions
    
    commit 8c8b9a9be2afa8bd6a72ad1130532baab9fab89d upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the control requests which erroneously used usb_rcvctrlpipe().
    
    Fixes: 8466028be792 ("V4L/DVB (8734): Initial support for AME DTV-5100 USB2.0 DVB-T")
    Cc: stable@vger.kernel.org      # 2.6.28
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 79666b99401652b696b64faecc8dc78b0abe36c4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jun 14 12:34:09 2021 +0200

    media: subdev: disallow ioctl for saa6588/davinci
    
    commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream.
    
    The saa6588_ioctl() function expects to get called from other kernel
    functions with a 'saa6588_command' pointer, but I found nothing stops it
    from getting called from user space instead, which seems rather dangerous.
    
    The same thing happens in the davinci vpbe driver with its VENC_GET_FLD
    command.
    
    As a quick fix, add a separate .command() callback pointer for this
    driver and change the two callers over to that.  This change can easily
    get backported to stable kernels if necessary, but since there are only
    two drivers, we may want to eventually replace this with a set of more
    specialized callbacks in the long run.
    
    Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2e0b80a74fc14af6aaf2b567f36a8ddbbc573d8b
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Jun 24 23:33:43 2021 +0200

    PCI: aardvark: Fix checking for PIO Non-posted Request
    
    commit 8ceeac307a79f68c0d0c72d6e48b82fa424204ec upstream.
    
    PIO_NON_POSTED_REQ for PIO_STAT register is incorrectly defined. Bit 10 in
    register PIO_STAT indicates the response is to a non-posted request.
    
    Link: https://lore.kernel.org/r/20210624213345.3617-2-pali@kernel.org
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Reviewed-by: Marek Behún <kabel@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d2c0c0516e63b71a3476d3b4b6d38406d237486
Author: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Date:   Fri May 21 02:55:01 2021 +0300

    PCI: Leave Apple Thunderbolt controllers on for s2idle or standby
    
    commit 4694ae373dc2114f9a82f6ae15737e65af0c6dea upstream.
    
    On Macbook 2013, resuming from suspend-to-idle or standby resulted in the
    external monitor no longer being detected, a stacktrace, and errors like
    this in dmesg:
    
      pcieport 0000:06:00.0: can't change power state from D3hot to D0 (config space inaccessible)
    
    The reason is that we know how to turn power to the Thunderbolt controller
    *off* via the SXIO/SXFP/SXLF methods, but we don't know how to turn power
    back on.  We have to rely on firmware to turn the power back on.
    
    When going to the "suspend-to-idle" or "standby" system sleep states,
    firmware is not involved either on the suspend side or the resume side, so
    we can't use SXIO/SXFP/SXLF to turn the power off.
    
    Skip SXIO/SXFP/SXLF when firmware isn't involved in suspend, e.g., when
    we're going to the "suspend-to-idle" or "standby" system sleep states.
    
    Fixes: 1df5172c5c25 ("PCI: Suspend/resume quirks for Apple thunderbolt")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212767
    Link: https://lore.kernel.org/r/20210520235501.917397-1-Hi-Angel@yandex.ru
    Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Lukas Wunner <lukas@wunner.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8fbae4a1bdb5b889490cdee929e68540151536e5
Author: Hou Tao <houtao1@huawei.com>
Date:   Thu Jun 17 15:45:47 2021 +0800

    dm btree remove: assign new_root only when removal succeeds
    
    commit b6e58b5466b2959f83034bead2e2e1395cca8aeb upstream.
    
    remove_raw() in dm_btree_remove() may fail due to IO read error
    (e.g. read the content of origin block fails during shadowing),
    and the value of shadow_spine::root is uninitialized, but
    the uninitialized value is still assign to new_root in the
    end of dm_btree_remove().
    
    For dm-thin, the value of pmd->details_root or pmd->root will become
    an uninitialized value, so if trying to read details_info tree again
    out-of-bound memory may occur as showed below:
    
      general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
      CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
      Hardware name: QEMU Standard PC
      RIP: 0010:metadata_ll_load_ie+0x14/0x30
      Call Trace:
       sm_metadata_count_is_more_than_one+0xb9/0xe0
       dm_tm_shadow_block+0x52/0x1c0
       shadow_step+0x59/0xf0
       remove_raw+0xb2/0x170
       dm_btree_remove+0xf4/0x1c0
       dm_pool_delete_thin_device+0xc3/0x140
       pool_message+0x218/0x2b0
       target_message+0x251/0x290
       ctl_ioctl+0x1c4/0x4d0
       dm_ctl_ioctl+0xe/0x20
       __x64_sys_ioctl+0x7b/0xb0
       do_syscall_64+0x40/0xb0
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixing it by only assign new_root when removal succeeds
    
    Signed-off-by: Hou Tao <houtao1@huawei.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04bd77ef4f4d9fc6102023b85f4590fc2130aac5
Author: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Date:   Mon Jun 14 11:59:00 2021 -0600

    coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()
    
    commit 5fae8a946ac2df879caf3f79a193d4766d00239b upstream.
    
    commit 6f755e85c332 ("coresight: Add helper for inserting synchronization
    packets") removed trailing '\0' from barrier_pkt array and updated the
    call sites like etb_update_buffer() to have proper checks for barrier_pkt
    size before read but missed updating tmc_update_etf_buffer() which still
    reads barrier_pkt past the array size resulting in KASAN out-of-bounds
    bug. Fix this by adding a check for barrier_pkt size before accessing
    like it is done in etb_update_buffer().
    
     BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698
     Read of size 4 at addr ffffffd05b7d1030 by task perf/2629
    
     Call trace:
      dump_backtrace+0x0/0x27c
      show_stack+0x20/0x2c
      dump_stack+0x11c/0x188
      print_address_description+0x3c/0x4a4
      __kasan_report+0x140/0x164
      kasan_report+0x10/0x18
      __asan_report_load4_noabort+0x1c/0x24
      tmc_update_etf_buffer+0x4b8/0x698
      etm_event_stop+0x248/0x2d8
      etm_event_del+0x20/0x2c
      event_sched_out+0x214/0x6f0
      group_sched_out+0xd0/0x270
      ctx_sched_out+0x2ec/0x518
      __perf_event_task_sched_out+0x4fc/0xe6c
      __schedule+0x1094/0x16a0
      preempt_schedule_irq+0x88/0x170
      arm64_preempt_schedule_irq+0xf0/0x18c
      el1_irq+0xe8/0x180
      perf_event_exec+0x4d8/0x56c
      setup_new_exec+0x204/0x400
      load_elf_binary+0x72c/0x18c0
      search_binary_handler+0x13c/0x420
      load_script+0x500/0x6c4
      search_binary_handler+0x13c/0x420
      exec_binprm+0x118/0x654
      __do_execve_file+0x77c/0xba4
      __arm64_compat_sys_execve+0x98/0xac
      el0_svc_common+0x1f8/0x5e0
      el0_svc_compat_handler+0x84/0xb0
      el0_svc_compat+0x10/0x50
    
     The buggy address belongs to the variable:
      barrier_pkt+0x10/0x40
    
     Memory state around the buggy address:
      ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
      ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03
                                          ^
      ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa
      ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa
     ==================================================================
    
    Link: https://lore.kernel.org/r/20210505093430.18445-1-saiprakash.ranjan@codeaurora.org
    Fixes: 0c3fc4d5fa26 ("coresight: Add barrier packet for synchronisation")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
    Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
    Link: https://lore.kernel.org/r/20210614175901.532683-6-mathieu.poirier@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a84f140380cc45b249f01b2cb856dbdd23e446a1
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Mon May 24 02:32:05 2021 -0700

    ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe
    
    commit 9272e5d0028d45a3b45b58c9255e6e0df53f7ad9 upstream.
    
    In the out_err_bus_register error branch of tpci200_pci_probe,
    tpci200->info->cfg_regs is freed by tpci200_uninstall()->
    tpci200_unregister()->pci_iounmap(..,tpci200->info->cfg_regs)
    in the first time.
    
    But later, iounmap() is called to free tpci200->info->cfg_regs
    again.
    
    My patch sets tpci200->info->cfg_regs to NULL after tpci200_uninstall()
    to avoid the double free.
    
    Fixes: cea2f7cdff2af ("Staging: ipack/bridges/tpci200: Use the TPCI200 in big endian mode")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Link: https://lore.kernel.org/r/20210524093205.8333-1-lyl2019@mail.ustc.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1105c6465e3a8f1616139caac6f299ae0a8082e
Author: Paul Burton <paulburton@google.com>
Date:   Thu Jul 1 10:24:07 2021 -0700

    tracing: Resize tgid_map to pid_max, not PID_MAX_DEFAULT
    
    commit 4030a6e6a6a4a42ff8c18414c9e0c93e24cc70b8 upstream.
    
    Currently tgid_map is sized at PID_MAX_DEFAULT entries, which means that
    on systems where pid_max is configured higher than PID_MAX_DEFAULT the
    ftrace record-tgid option doesn't work so well. Any tasks with PIDs
    higher than PID_MAX_DEFAULT are simply not recorded in tgid_map, and
    don't show up in the saved_tgids file.
    
    In particular since systemd v243 & above configure pid_max to its
    highest possible 1<<22 value by default on 64 bit systems this renders
    the record-tgids option of little use.
    
    Increase the size of tgid_map to the configured pid_max instead,
    allowing it to cover the full range of PIDs up to the maximum value of
    PID_MAX_LIMIT if the system is configured that way.
    
    On 64 bit systems with pid_max == PID_MAX_LIMIT this will increase the
    size of tgid_map from 256KiB to 16MiB. Whilst this 64x increase in
    memory overhead sounds significant 64 bit systems are presumably best
    placed to accommodate it, and since tgid_map is only allocated when the
    record-tgid option is actually used presumably the user would rather it
    spends sufficient memory to actually record the tgids they expect.
    
    The size of tgid_map could also increase for CONFIG_BASE_SMALL=y
    configurations, but these seem unlikely to be systems upon which people
    are both configuring a large pid_max and running ftrace with record-tgid
    anyway.
    
    Of note is that we only allocate tgid_map once, the first time that the
    record-tgid option is enabled. Therefore its size is only set once, to
    the value of pid_max at the time the record-tgid option is first
    enabled. If a user increases pid_max after that point, the saved_tgids
    file will not contain entries for any tasks with pids beyond the earlier
    value of pid_max.
    
    Link: https://lkml.kernel.org/r/20210701172407.889626-2-paulburton@google.com
    
    Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks")
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Joel Fernandes <joelaf@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Paul Burton <paulburton@google.com>
    [ Fixed comment coding style ]
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44896b31b19c7012d1fd8548f3dd82f272c03063
Author: Paul Burton <paulburton@google.com>
Date:   Tue Jun 29 17:34:05 2021 -0700

    tracing: Simplify & fix saved_tgids logic
    
    commit b81b3e959adb107cd5b36c7dc5ba1364bbd31eb2 upstream.
    
    The tgid_map array records a mapping from pid to tgid, where the index
    of an entry within the array is the pid & the value stored at that index
    is the tgid.
    
    The saved_tgids_next() function iterates over pointers into the tgid_map
    array & dereferences the pointers which results in the tgid, but then it
    passes that dereferenced value to trace_find_tgid() which treats it as a
    pid & does a further lookup within the tgid_map array. It seems likely
    that the intent here was to skip over entries in tgid_map for which the
    recorded tgid is zero, but instead we end up skipping over entries for
    which the thread group leader hasn't yet had its own tgid recorded in
    tgid_map.
    
    A minimal fix would be to remove the call to trace_find_tgid, turning:
    
      if (trace_find_tgid(*ptr))
    
    into:
    
      if (*ptr)
    
    ..but it seems like this logic can be much simpler if we simply let
    seq_read() iterate over the whole tgid_map array & filter out empty
    entries by returning SEQ_SKIP from saved_tgids_show(). Here we take that
    approach, removing the incorrect logic here entirely.
    
    Link: https://lkml.kernel.org/r/20210630003406.4013668-1-paulburton@google.com
    
    Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks")
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Joel Fernandes <joelaf@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Paul Burton <paulburton@google.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4c6061fccee64b2072b28dfa3e93cf859c4c0a
Author: Yun Zhou <yun.zhou@windriver.com>
Date:   Sat Jun 26 11:21:55 2021 +0800

    seq_buf: Fix overflow in seq_buf_putmem_hex()
    
    commit d3b16034a24a112bb83aeb669ac5b9b01f744bb7 upstream.
    
    There's two variables being increased in that loop (i and j), and i
    follows the raw data, and j follows what is being written into the buffer.
    We should compare 'i' to MAX_MEMHEX_BYTES or compare 'j' to HEX_CHARS.
    Otherwise, if 'j' goes bigger than HEX_CHARS, it will overflow the
    destination buffer.
    
    Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/
    Link: https://lkml.kernel.org/r/20210626032156.47889-1-yun.zhou@windriver.com
    
    Cc: stable@vger.kernel.org
    Fixes: 5e3ca0ec76fce ("ftrace: introduce the "hex" output method")
    Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b35bd56fcfcecad8f2b90e4cf13053a04b7ef058
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sun Jun 27 01:47:49 2021 +0200

    power: supply: ab8500: Fix an old bug
    
    commit f1c74a6c07e76fcb31a4bcc1f437c4361a2674ce upstream.
    
    Trying to get the AB8500 charging driver working I ran into a bit
    of bitrot: we haven't used the driver for a while so errors in
    refactorings won't be noticed.
    
    This one is pretty self evident: use argument to the macro or we
    end up with a random pointer to something else.
    
    Cc: stable@vger.kernel.org
    Cc: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: Marcus Cooper <codekipper@gmail.com>
    Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba7f895082ab3a89a5e9da2730474dbae7f79988
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Thu May 13 14:26:36 2021 +0200

    ipmi/watchdog: Stop watchdog timer when the current action is 'none'
    
    commit 2253042d86f57d90a621ac2513a7a7a13afcf809 upstream.
    
    When an IPMI watchdog timer is being stopped in ipmi_close() or
    ipmi_ioctl(WDIOS_DISABLECARD), the current watchdog action is updated to
    WDOG_TIMEOUT_NONE and _ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB) is called
    to install this action. The latter function ends up invoking
    __ipmi_set_timeout() which makes the actual 'Set Watchdog Timer' IPMI
    request.
    
    For IPMI 1.0, this operation results in fully stopping the watchdog timer.
    For IPMI >= 1.5, function __ipmi_set_timeout() always specifies the "don't
    stop" flag in the prepared 'Set Watchdog Timer' IPMI request. This causes
    that the watchdog timer has its action correctly updated to 'none' but the
    timer continues to run. A problem is that IPMI firmware can then still log
    an expiration event when the configured timeout is reached, which is
    unexpected because the watchdog timer was requested to be stopped.
    
    The patch fixes this problem by not setting the "don't stop" flag in
    __ipmi_set_timeout() when the current action is WDOG_TIMEOUT_NONE which
    results in stopping the watchdog timer. This makes the behaviour for
    IPMI >= 1.5 consistent with IPMI 1.0. It also matches the logic in
    __ipmi_heartbeat() which does not allow to reset the watchdog if the
    current action is WDOG_TIMEOUT_NONE as that would start the timer.
    
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Message-Id: <10a41bdc-9c99-089c-8d89-fa98ce5ea080@suse.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19f862a7f53ac2f84413dc7ebcb3819d889670d4
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Feb 11 12:42:58 2021 -0700

    qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute
    
    commit fca41af18e10318e4de090db47d9fa7169e1bf2f upstream.
    
    fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
    which violates clang's CFI checking because fw_cfg_showrev()'s second
    parameter is 'struct attribute', whereas the ->show() member of 'struct
    kobj_structure' expects the second parameter to be of type 'struct
    kobj_attribute'.
    
    $ cat /sys/firmware/qemu_fw_cfg/rev
    3
    
    $ dmesg | grep "CFI failure"
    [   26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):
    
    Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
    this would have been caught automatically by the incompatible pointer
    types compiler warning. Update fw_cfg_showrev() accordingly.
    
    Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
    Link: https://github.com/ClangBuiltLinux/linux/issues/1299
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4587b665988ff6b3de070508fbcfb9b4615f3414
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sat May 29 18:46:46 2021 +0300

    ASoC: tegra: Set driver_name=tegra for all machine drivers
    
    commit f6eb84fa596abf28959fc7e0b626f925eb1196c7 upstream.
    
    The driver_name="tegra" is now required by the newer ALSA UCMs, otherwise
    Tegra UCMs don't match by the path/name.
    
    All Tegra machine drivers are specifying the card's name, but it has no
    effect if model name is specified in the device-tree since it overrides
    the card's name. We need to set the driver_name to "tegra" in order to
    get a usable lookup path for the updated ALSA UCMs. The new UCM lookup
    path has a form of driver_name/card_name.
    
    The old lookup paths that are based on driver module name continue to
    work as before. Note that UCM matching never worked for Tegra ASoC drivers
    if they were compiled as built-in, this is fixed by supporting the new
    naming scheme.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20210529154649.25936-2-digetx@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24493605bd1c9e56cb0229c8e006e3add2f0b706
Author: Samuel Holland <samuel@sholland.org>
Date:   Fri May 14 21:14:39 2021 -0500

    clocksource/arm_arch_timer: Improve Allwinner A64 timer workaround
    
    commit 8b33dfe0ba1c84c1aab2456590b38195837f1e6e upstream.
    
    Bad counter reads are experienced sometimes when bit 10 or greater rolls
    over. Originally, testing showed that at least 10 lower bits would be
    set to the same value during these bad reads. However, some users still
    reported time skips.
    
    Wider testing revealed that on some chips, occasionally only the lowest
    9 bits would read as the anomalous value. During these reads (which
    still happen only when bit 10), bit 9 would read as the correct value.
    
    Reduce the mask by one bit to cover these cases as well.
    
    Cc: stable@vger.kernel.org
    Fixes: c950ca8c35ee ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability")
    Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
    Signed-off-by: Samuel Holland <samuel@sholland.org>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20210515021439.55316-1-samuel@sholland.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7cb77faedaf57ebb8b5c80e99264998ac977a257
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Mar 27 22:01:36 2021 +0100

    cpu/hotplug: Cure the cpusets trainwreck
    
    commit b22afcdf04c96ca58327784e280e10288cfd3303 upstream.
    
    Alexey and Joshua tried to solve a cpusets related hotplug problem which is
    user space visible and results in unexpected behaviour for some time after
    a CPU has been plugged in and the corresponding uevent was delivered.
    
    cpusets delegate the hotplug work (rebuilding cpumasks etc.) to a
    workqueue. This is done because the cpusets code has already a lock
    nesting of cgroups_mutex -> cpu_hotplug_lock. A synchronous callback or
    waiting for the work to finish with cpu_hotplug_lock held can and will
    deadlock because that results in the reverse lock order.
    
    As a consequence the uevent can be delivered before cpusets have consistent
    state which means that a user space invocation of sched_setaffinity() to
    move a task to the plugged CPU fails up to the point where the scheduled
    work has been processed.
    
    The same is true for CPU unplug, but that does not create user observable
    failure (yet).
    
    It's still inconsistent to claim that an operation is finished before it
    actually is and that's the real issue at hand. uevents just make it
    reliably observable.
    
    Obviously the problem should be fixed in cpusets/cgroups, but untangling
    that is pretty much impossible because according to the changelog of the
    commit which introduced this 8 years ago:
    
     3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
    
    the lock order cgroups_mutex -> cpu_hotplug_lock is a design decision and
    the whole code is built around that.
    
    So bite the bullet and invoke the relevant cpuset function, which waits for
    the work to finish, in _cpu_up/down() after dropping cpu_hotplug_lock and
    only when tasks are not frozen by suspend/hibernate because that would
    obviously wait forever.
    
    Waiting there with cpu_add_remove_lock, which is protecting the present
    and possible CPU maps, held is not a problem at all because neither work
    queues nor cpusets/cgroups have any lockchains related to that lock.
    
    Waiting in the hotplug machinery is not problematic either because there
    are already state callbacks which wait for hardware queues to drain. It
    makes the operations slightly slower, but hotplug is slow anyway.
    
    This ensures that state is consistent before returning from a hotplug
    up/down operation. It's still inconsistent during the operation, but that's
    a different story.
    
    Add a large comment which explains why this is done and why this is not a
    dump ground for the hack of the day to work around half thought out locking
    schemes. Document also the implications vs. hotplug operations and
    serialization or the lack of it.
    
    Thanks to Alexy and Joshua for analyzing why this temporary
    sched_setaffinity() failure happened.
    
    Fixes: 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()")
    Reported-by: Alexey Klimov <aklimov@redhat.com>
    Reported-by: Joshua Baker <jobaker@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Alexey Klimov <aklimov@redhat.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87tuowcnv3.ffs@nanos.tec.linutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 999daeb164e252d5f2378f03cb996ee4241cb61d
Author: Timo Sigurdsson <public_timo.s@silentcreek.de>
Date:   Mon Jun 14 09:25:39 2021 +0200

    ata: ahci_sunxi: Disable DIPM
    
    commit f6bca4d91b2ea052e917cca3f9d866b5cc1d500a upstream.
    
    DIPM is unsupported or broken on sunxi. Trying to enable the power
    management policy med_power_with_dipm on an Allwinner A20 SoC based board
    leads to immediate I/O errors and the attached SATA disk disappears from
    the /dev filesystem. A reset (power cycle) is required to make the SATA
    controller or disk work again. The A10 and A20 SoC data sheets and manuals
    don't mention DIPM at all [1], so it's fair to assume that it's simply not
    supported. But even if it was, it should be considered broken and best be
    disabled in the ahci_sunxi driver.
    
    [1] https://github.com/allwinner-zh/documents/tree/master/
    
    Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform")
    Cc: stable@vger.kernel.org
    Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
    Tested-by: Timo Sigurdsson <public_timo.s@silentcreek.de>
    Link: https://lore.kernel.org/r/20210614072539.3307-1-public_timo.s@silentcreek.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f7589b0224e46cdc5fe8f03d7aec08e023b491a9
Author: Christian Löhle <CLoehle@hyperstone.com>
Date:   Wed May 12 16:03:24 2021 +0000

    mmc: core: Allow UHS-I voltage switch for SDSC cards if supported
    
    commit 09247e110b2efce3a104e57e887c373e0a57a412 upstream.
    
    While initializing an UHS-I SD card, the mmc core first tries to switch to
    1.8V I/O voltage, before it continues to change the settings for the bus
    speed mode.
    
    However, the current behaviour in the mmc core is inconsistent and doesn't
    conform to the SD spec. More precisely, an SD card that supports UHS-I must
    set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register
    response. When switching to 1.8V I/O the mmc core correctly checks both of
    the bits, but only the SD_OCR_S18R bit when changing the settings for bus
    speed mode.
    
    Rather than actually fixing the code to confirm to the SD spec, let's
    deliberately deviate from it by requiring only the SD_OCR_S18R bit for both
    parts. This enables us to support UHS-I for SDSC cards (outside spec),
    which is actually being supported by some existing SDSC cards. Moreover,
    this fixes the inconsistent behaviour.
    
    Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
    Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM
    Cc: stable@vger.kernel.org
    [Ulf: Rewrote commit message and comments to clarify the changes]
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdfa7b1008d9f7258818221d7500da9e0f848f50
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jun 24 17:16:14 2021 +0200

    mmc: core: clear flags before allowing to retune
    
    commit 77347eda64ed5c9383961d1de9165f9d0b7d8df6 upstream.
    
    It might be that something goes wrong during tuning so the MMC core will
    immediately trigger a retune. In our case it was:
    
     - we sent a tuning block
     - there was an error so we need to send an abort cmd to the eMMC
     - the abort cmd had a CRC error
     - retune was set by the MMC core
    
    This lead to a vicious circle causing a performance regression of 75%.
    So, clear retuning flags before we enable retuning to start with a known
    cleared state.
    
    Reported-by Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 357251e565560e014acb9180ec9093fc2156241f
Author: Al Cooper <alcooperx@gmail.com>
Date:   Thu Jun 24 12:30:45 2021 -0400

    mmc: sdhci: Fix warning message when accessing RPMB in HS400 mode
    
    commit d0244847f9fc5e20df8b7483c8a4717fe0432d38 upstream.
    
    When an eMMC device is being run in HS400 mode, any access to the
    RPMB device will cause the error message "mmc1: Invalid UHS-I mode
    selected". This happens as a result of tuning being disabled before
    RPMB access and then re-enabled after the RPMB access is complete.
    When tuning is re-enabled, the system has to switch from HS400
    to HS200 to do the tuning and then back to HS400. As part of
    sequence to switch from HS400 to HS200 the system is temporarily
    put into HS mode. When switching to HS mode, sdhci_get_preset_value()
    is called and does not have support for HS mode and prints the warning
    message and returns the preset for SDR12. The fix is to add support
    for MMC and SD HS modes to sdhci_get_preset_value().
    
    This can be reproduced on any system running eMMC in HS400 mode
    (not HS400ES) by using the "mmc" utility to run the following
    command: "mmc rpmb read-counter /dev/mmcblk0rpmb".
    
    Signed-off-by: Al Cooper <alcooperx@gmail.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210624163045.33651-1-alcooperx@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5792b74025cd4a80377057b55bc27c3f68c15a7d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 27 11:20:15 2021 +0200

    drm/msm/mdp4: Fix modifier support enabling
    
    commit 35cbb8c91e9cf310277d3dfb4d046df8edf2df33 upstream.
    
    Setting the cap without the modifier list is very confusing to
    userspace. Fix that by listing the ones we support explicitly.
    
    Stable backport so that userspace can rely on this working in a
    reasonable way, i.e. that the cap set implies IN_FORMATS is available.
    
    Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Cc: stable@vger.kernel.org
    Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
    Cc: Rob Clark <robdclark@chromium.org>
    Cc: Jordan Crouse <jordan@cosmicpenguin.net>
    Cc: Emil Velikov <emil.velikov@collabora.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-5-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b52ba58f14032cc649396994c1236587c9da400
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Wed May 12 23:03:16 2021 +0200

    pinctrl/amd: Add device HID for new AMD GPIO controller
    
    commit 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b upstream.
    
    Add device HID AMDI0031 to the AMD GPIO controller driver match table.
    This controller can be found on Microsoft Surface Laptop 4 devices and
    seems similar enough that we can just copy the existing AMDI0030 entry.
    
    Cc: <stable@vger.kernel.org> # 5.10+
    Tested-by: Sachi King <nakato@nakato.io>
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20210512210316.1982416-1-luzmaximilian@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39f93baead1e8af115b4be180031162d09f77e32
Author: Guchun Chen <guchun.chen@amd.com>
Date:   Mon Jun 28 17:03:48 2021 +0800

    drm/amd/display: fix incorrrect valid irq check
    
    commit e38ca7e422791a4d1c01e56dbf7f9982db0ed365 upstream.
    
    valid DAL irq should be < DAL_IRQ_SOURCES_NUMBER.
    
    Signed-off-by: Guchun Chen <guchun.chen@amd.com>
    Reviewed-and-tested-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bde0f98f32bee955c4f83ae6683459244abff7e6
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Tue Jun 29 19:44:55 2021 +0800

    drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()
    
    commit 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 upstream.
    
    radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
    an error path. Add the missed function call to fix it.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 86f8b0e62ac7cac4423d48ca3d3ba38f2dc5c80d
Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Date:   Thu Jun 3 12:15:07 2021 -0500

    usb: gadget: f_fs: Fix setting of device and driver data cross-references
    
    commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 upstream.
    
    FunctionFS device structure 'struct ffs_dev' and driver data structure
    'struct ffs_data' are bound to each other with cross-reference pointers
    'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one
    is supposed to be valid through the whole life of 'struct ffs_data'
    (and while 'struct ffs_dev' exists non-freed), the second one is cleared
    in 'ffs_closed()' (called from 'ffs_data_reset()' or the last
    'ffs_data_put()'). This can be called several times, alternating in
    different order with 'ffs_free_inst()', that, if possible, clears
    the other cross-reference.
    
    As a result, different cases of these calls order may leave stale
    cross-reference pointers, used when the pointed structure is already
    freed. Even if it occasionally doesn't cause kernel crash, this error
    is reported by KASAN-enabled kernel configuration.
    
    For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was
    fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in
    ffs_free_inst").
    
    The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()']
    now causes KASAN reported error [1], when 'ffs_data_reset()' clears
    'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev',
    but can't clear 'ffs_data->private_data', which is then accessed
    in 'ffs_closed()' called from 'ffs_data_put()'. This happens since
    'ffs_dev->ffs_data' reference is cleared too early.
    
    Moreover, one more use case, when 'ffs_free_inst()' is called immediately
    after mounting FunctionFS device (that is before the descriptors are
    written and 'ffs_ready()' is called), and then 'ffs_data_reset()'
    or 'ffs_data_put()' is called from accessing "ep0" file or unmounting
    the device. This causes KASAN error report like [2], since
    'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly
    clear 'ffs_data->private_data', that is later accessed to freed structure.
    
    Fix these (and may be other) cases of stale pointers access by moving
    setting and clearing of the mentioned cross-references to the single
    places, setting both of them when 'struct ffs_data' is created and
    bound to 'struct ffs_dev', and clearing both of them when one of the
    structures is destroyed. It seems convenient to make this pointer
    initialization and structures binding in 'ffs_acquire_dev()' and
    make pointers clearing in 'ffs_release_dev()'. This required some
    changes in these functions parameters and return types.
    
    Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor
    issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()'
    is called without unmounting the device, and "release_dev" callback
    is not called at all, or (2) "release_dev" callback is called before
    "ffs_closed" callback on unmounting, which seems to be not correctly
    nested with "acquire_dev" and "ffs_ready" callbacks.
    Make this cleanup togther with other mentioned 'ffs_release_dev()' changes.
    
    [1]
    ==================================================================
    root@rcar-gen3:~# mkdir /dev/cfs
    root@rcar-gen3:~# mkdir /dev/ffs
    root@rcar-gen3:~# modprobe libcomposite
    root@rcar-gen3:~# mount -t configfs none /dev/cfs
    root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
    root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
    [   64.340664] file system registered
    root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
    root@rcar-gen3:~# cd /dev/ffs
    root@rcar-gen3:/dev/ffs# /home/root/ffs-test
    ffs-test: info: ep0: writing descriptors (in v2 format)
    [   83.181442] read descriptors
    [   83.186085] read strings
    ffs-test: info: ep0: writing strings
    ffs-test: dbg:  ep1: starting
    ffs-test: dbg:  ep2: starting
    ffs-test: info: ep1: starts
    ffs-test: info: ep2: starts
    ffs-test: info: ep0: starts
    
    ^C
    root@rcar-gen3:/dev/ffs# cd /home/root/
    root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
    [   98.935061] unloading
    root@rcar-gen3:~# umount /dev/ffs
    [  102.734301] ==================================================================
    [  102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs]
    [  102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997
    [  102.756709]
    [  102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8
    [  102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
    [  102.772179] Call trace:
    [  102.774779]  dump_backtrace+0x0/0x330
    [  102.778653]  show_stack+0x20/0x2c
    [  102.782152]  dump_stack+0x11c/0x1ac
    [  102.785833]  print_address_description.constprop.0+0x30/0x274
    [  102.791862]  kasan_report+0x14c/0x1c8
    [  102.795719]  __asan_report_store1_noabort+0x34/0x58
    [  102.800840]  ffs_release_dev+0x64/0xa8 [usb_f_fs]
    [  102.805801]  ffs_fs_kill_sb+0x50/0x84 [usb_f_fs]
    [  102.810663]  deactivate_locked_super+0xa0/0xf0
    [  102.815339]  deactivate_super+0x98/0xac
    [  102.819378]  cleanup_mnt+0xd0/0x1b0
    [  102.823057]  __cleanup_mnt+0x1c/0x28
    [  102.826823]  task_work_run+0x104/0x180
    [  102.830774]  do_notify_resume+0x458/0x14e0
    [  102.835083]  work_pending+0xc/0x5f8
    [  102.838762]
    [  102.840357] Allocated by task 2988:
    [  102.844032]  kasan_save_stack+0x28/0x58
    [  102.848071]  kasan_set_track+0x28/0x3c
    [  102.852016]  ____kasan_kmalloc+0x84/0x9c
    [  102.856142]  __kasan_kmalloc+0x10/0x1c
    [  102.860088]  __kmalloc+0x214/0x2f8
    [  102.863678]  kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
    [  102.868990]  ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
    [  102.873942]  try_get_usb_function_instance+0xf0/0x164 [libcomposite]
    [  102.880629]  usb_get_function_instance+0x64/0x68 [libcomposite]
    [  102.886858]  function_make+0x128/0x1ec [libcomposite]
    [  102.892185]  configfs_mkdir+0x330/0x590 [configfs]
    [  102.897245]  vfs_mkdir+0x12c/0x1bc
    [  102.900835]  do_mkdirat+0x180/0x1d0
    [  102.904513]  __arm64_sys_mkdirat+0x80/0x94
    [  102.908822]  invoke_syscall+0xf8/0x25c
    [  102.912772]  el0_svc_common.constprop.0+0x150/0x1a0
    [  102.917891]  do_el0_svc+0xa0/0xd4
    [  102.921386]  el0_svc+0x24/0x34
    [  102.924613]  el0_sync_handler+0xcc/0x154
    [  102.928743]  el0_sync+0x198/0x1c0
    [  102.932238]
    [  102.933832] Freed by task 2996:
    [  102.937144]  kasan_save_stack+0x28/0x58
    [  102.941181]  kasan_set_track+0x28/0x3c
    [  102.945128]  kasan_set_free_info+0x28/0x4c
    [  102.949435]  ____kasan_slab_free+0x104/0x118
    [  102.953921]  __kasan_slab_free+0x18/0x24
    [  102.958047]  slab_free_freelist_hook+0x148/0x1f0
    [  102.962897]  kfree+0x318/0x440
    [  102.966123]  ffs_free_inst+0x164/0x2d8 [usb_f_fs]
    [  102.971075]  usb_put_function_instance+0x84/0xa4 [libcomposite]
    [  102.977302]  ffs_attr_release+0x18/0x24 [usb_f_fs]
    [  102.982344]  config_item_put+0x140/0x1a4 [configfs]
    [  102.987486]  configfs_rmdir+0x3fc/0x518 [configfs]
    [  102.992535]  vfs_rmdir+0x114/0x234
    [  102.996122]  do_rmdir+0x274/0x2b0
    [  102.999617]  __arm64_sys_unlinkat+0x94/0xc8
    [  103.004015]  invoke_syscall+0xf8/0x25c
    [  103.007961]  el0_svc_common.constprop.0+0x150/0x1a0
    [  103.013080]  do_el0_svc+0xa0/0xd4
    [  103.016575]  el0_svc+0x24/0x34
    [  103.019801]  el0_sync_handler+0xcc/0x154
    [  103.023930]  el0_sync+0x198/0x1c0
    [  103.027426]
    [  103.029020] The buggy address belongs to the object at ffff0004d46ff500
    [  103.029020]  which belongs to the cache kmalloc-128 of size 128
    [  103.042079] The buggy address is located 73 bytes inside of
    [  103.042079]  128-byte region [ffff0004d46ff500, ffff0004d46ff580)
    [  103.054236] The buggy address belongs to the page:
    [  103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe
    [  103.070437] head:0000000021aa849b order:1 compound_mapcount:0
    [  103.076456] flags: 0x8000000000010200(slab|head|zone=2)
    [  103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300
    [  103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000
    [  103.098150] page dumped because: kasan: bad access detected
    [  103.103985]
    [  103.105578] Memory state around the buggy address:
    [  103.110602]  ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  103.118161]  ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  103.133284]                                               ^
    [  103.139120]  ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [  103.146679]  ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [  103.154238] ==================================================================
    [  103.161792] Disabling lock debugging due to kernel taint
    [  103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e
    [  103.175406] Mem abort info:
    [  103.178457]   ESR = 0x96000004
    [  103.181609]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  103.187020]   SET = 0, FnV = 0
    [  103.190185]   EA = 0, S1PTW = 0
    [  103.193417] Data abort info:
    [  103.196385]   ISV = 0, ISS = 0x00000004
    [  103.200315]   CM = 0, WnR = 0
    [  103.203366] [0037801d6000018e] address between user and kernel address ranges
    [  103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [  103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4
    [  103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G    B             5.13.0-rc4+ #8
    [  103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
    [  103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
    [  103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
    [  103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
    [  103.290385] sp : ffff800014777a80
    [  103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000
    [  103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4
    [  103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0
    [  103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000
    [  103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    [  103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658
    [  103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648
    [  103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000
    [  103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001
    [  103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70
    [  103.365766] Call trace:
    [  103.368235]  ffs_data_clear+0x138/0x370 [usb_f_fs]
    [  103.373076]  ffs_data_reset+0x20/0x304 [usb_f_fs]
    [  103.377829]  ffs_data_closed+0x1ec/0x244 [usb_f_fs]
    [  103.382755]  ffs_fs_kill_sb+0x70/0x84 [usb_f_fs]
    [  103.387420]  deactivate_locked_super+0xa0/0xf0
    [  103.391905]  deactivate_super+0x98/0xac
    [  103.395776]  cleanup_mnt+0xd0/0x1b0
    [  103.399299]  __cleanup_mnt+0x1c/0x28
    [  103.402906]  task_work_run+0x104/0x180
    [  103.406691]  do_notify_resume+0x458/0x14e0
    [  103.410823]  work_pending+0xc/0x5f8
    [  103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
    [  103.420490] ---[ end trace 57b43a50e8244f57 ]---
    Segmentation fault
    root@rcar-gen3:~#
    ==================================================================
    
    [2]
    ==================================================================
    root@rcar-gen3:~# mkdir /dev/ffs
    root@rcar-gen3:~# modprobe libcomposite
    root@rcar-gen3:~#
    root@rcar-gen3:~# mount -t configfs none /dev/cfs
    root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1
    root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
    [   54.766480] file system registered
    root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs
    root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs
    [   63.197597] unloading
    root@rcar-gen3:~# cat /dev/ffs/ep0
    cat: read error:[   67.213506] ==================================================================
    [   67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs]
    [   67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994
    [   67.236446]
    [   67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8
    [   67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
    [   67.251624] Call trace:
    [   67.254212]  dump_backtrace+0x0/0x330
    [   67.258081]  show_stack+0x20/0x2c
    [   67.261579]  dump_stack+0x11c/0x1ac
    [   67.265260]  print_address_description.constprop.0+0x30/0x274
    [   67.271286]  kasan_report+0x14c/0x1c8
    [   67.275143]  __asan_report_store1_noabort+0x34/0x58
    [   67.280265]  ffs_data_clear+0x70/0x370 [usb_f_fs]
    [   67.285220]  ffs_data_reset+0x20/0x304 [usb_f_fs]
    [   67.290172]  ffs_data_closed+0x240/0x244 [usb_f_fs]
    [   67.295305]  ffs_ep0_release+0x40/0x54 [usb_f_fs]
    [   67.300256]  __fput+0x304/0x580
    [   67.303576]  ____fput+0x18/0x24
    [   67.306893]  task_work_run+0x104/0x180
    [   67.310846]  do_notify_resume+0x458/0x14e0
    [   67.315154]  work_pending+0xc/0x5f8
    [   67.318834]
    [   67.320429] Allocated by task 2988:
    [   67.324105]  kasan_save_stack+0x28/0x58
    [   67.328144]  kasan_set_track+0x28/0x3c
    [   67.332090]  ____kasan_kmalloc+0x84/0x9c
    [   67.336217]  __kasan_kmalloc+0x10/0x1c
    [   67.340163]  __kmalloc+0x214/0x2f8
    [   67.343754]  kzalloc.constprop.0+0x14/0x20 [usb_f_fs]
    [   67.349066]  ffs_alloc_inst+0x8c/0x208 [usb_f_fs]
    [   67.354017]  try_get_usb_function_instance+0xf0/0x164 [libcomposite]
    [   67.360705]  usb_get_function_instance+0x64/0x68 [libcomposite]
    [   67.366934]  function_make+0x128/0x1ec [libcomposite]
    [   67.372260]  configfs_mkdir+0x330/0x590 [configfs]
    [   67.377320]  vfs_mkdir+0x12c/0x1bc
    [   67.380911]  do_mkdirat+0x180/0x1d0
    [   67.384589]  __arm64_sys_mkdirat+0x80/0x94
    [   67.388899]  invoke_syscall+0xf8/0x25c
    [   67.392850]  el0_svc_common.constprop.0+0x150/0x1a0
    [   67.397969]  do_el0_svc+0xa0/0xd4
    [   67.401464]  el0_svc+0x24/0x34
    [   67.404691]  el0_sync_handler+0xcc/0x154
    [   67.408819]  el0_sync+0x198/0x1c0
    [   67.412315]
    [   67.413909] Freed by task 2993:
    [   67.417220]  kasan_save_stack+0x28/0x58
    [   67.421257]  kasan_set_track+0x28/0x3c
    [   67.425204]  kasan_set_free_info+0x28/0x4c
    [   67.429513]  ____kasan_slab_free+0x104/0x118
    [   67.434001]  __kasan_slab_free+0x18/0x24
    [   67.438128]  slab_free_freelist_hook+0x148/0x1f0
    [   67.442978]  kfree+0x318/0x440
    [   67.446205]  ffs_free_inst+0x164/0x2d8 [usb_f_fs]
    [   67.451156]  usb_put_function_instance+0x84/0xa4 [libcomposite]
    [   67.457385]  ffs_attr_release+0x18/0x24 [usb_f_fs]
    [   67.462428]  config_item_put+0x140/0x1a4 [configfs]
    [   67.467570]  configfs_rmdir+0x3fc/0x518 [configfs]
    [   67.472626]  vfs_rmdir+0x114/0x234
    [   67.476215]  do_rmdir+0x274/0x2b0
    [   67.479710]  __arm64_sys_unlinkat+0x94/0xc8
    [   67.484108]  invoke_syscall+0xf8/0x25c
    [   67.488055]  el0_svc_common.constprop.0+0x150/0x1a0
    [   67.493175]  do_el0_svc+0xa0/0xd4
    [   67.496671]  el0_svc+0x24/0x34
    [   67.499896]  el0_sync_handler+0xcc/0x154
    [   67.504024]  el0_sync+0x198/0x1c0
    [   67.507520]
    [   67.509114] The buggy address belongs to the object at ffff0004c26e9700
    [   67.509114]  which belongs to the cache kmalloc-128 of size 128
    [   67.522171] The buggy address is located 74 bytes inside of
    [   67.522171]  128-byte region [ffff0004c26e9700, ffff0004c26e9780)
    [   67.534328] The buggy address belongs to the page:
    [   67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8
    [   67.549175] head:000000003177a217 order:1 compound_mapcount:0
    [   67.555195] flags: 0x8000000000010200(slab|head|zone=2)
    [   67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300
    [   67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
    [   67.576890] page dumped because: kasan: bad access detected
    [   67.582725]
    [   67.584318] Memory state around the buggy address:
    [   67.589343]  ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   67.596903]  ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   67.612022]                                               ^
    [   67.617860]  ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   67.625421]  ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    [   67.632981] ==================================================================
    [   67.640535] Disabling lock debugging due to kernel taint
     File descriptor[   67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d
     in bad state
    [   67.655456] Mem abort info:
    [   67.659619]   ESR = 0x96000004
    [   67.662801]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   67.668225]   SET = 0, FnV = 0
    [   67.671375]   EA = 0, S1PTW = 0
    [   67.674613] Data abort info:
    [   67.677587]   ISV = 0, ISS = 0x00000004
    [   67.681522]   CM = 0, WnR = 0
    [   67.684588] [fabb801d4000018d] address between user and kernel address ranges
    [   67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [   67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4
    [   67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G    B             5.13.0-rc4+ #8
    [   67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT)
    [   67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
    [   67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs]
    [   67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs]
    [   67.771365] sp : ffff800014767ad0
    [   67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0
    [   67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d
    [   67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0
    [   67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000
    [   67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    [   67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa
    [   67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014
    [   67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000
    [   67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001
    [   67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d
    [   67.846748] Call trace:
    [   67.849218]  ffs_data_clear+0x138/0x370 [usb_f_fs]
    [   67.854058]  ffs_data_reset+0x20/0x304 [usb_f_fs]
    [   67.858810]  ffs_data_closed+0x240/0x244 [usb_f_fs]
    [   67.863736]  ffs_ep0_release+0x40/0x54 [usb_f_fs]
    [   67.868488]  __fput+0x304/0x580
    [   67.871665]  ____fput+0x18/0x24
    [   67.874837]  task_work_run+0x104/0x180
    [   67.878622]  do_notify_resume+0x458/0x14e0
    [   67.882754]  work_pending+0xc/0x5f8
    [   67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821)
    [   67.892422] ---[ end trace 6d7cedf53d7abbea ]---
    Segmentation fault
    root@rcar-gen3:~#
    ==================================================================
    
    Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code")
    Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
    Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst")
    Reported-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
    Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
    Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com
    [agabbasov: Backported to earlier mount API, resolved context conflicts]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1525e3556731df38b57d06afc6e7c4e5cb29596b
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Fri May 28 11:27:52 2021 -0700

    powerpc/barrier: Avoid collision with clang's __lwsync macro
    
    commit 015d98149b326e0f1f02e44413112ca8b4330543 upstream.
    
    A change in clang 13 results in the __lwsync macro being defined as
    __builtin_ppc_lwsync, which emits 'lwsync' or 'msync' depending on what
    the target supports. This breaks the build because of -Werror in
    arch/powerpc, along with thousands of warnings:
    
     In file included from arch/powerpc/kernel/pmc.c:12:
     In file included from include/linux/bug.h:5:
     In file included from arch/powerpc/include/asm/bug.h:109:
     In file included from include/asm-generic/bug.h:20:
     In file included from include/linux/kernel.h:12:
     In file included from include/linux/bitops.h:32:
     In file included from arch/powerpc/include/asm/bitops.h:62:
     arch/powerpc/include/asm/barrier.h:49:9: error: '__lwsync' macro redefined [-Werror,-Wmacro-redefined]
     #define __lwsync()      __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory")
            ^
     <built-in>:308:9: note: previous definition is here
     #define __lwsync __builtin_ppc_lwsync
            ^
     1 error generated.
    
    Undefine this macro so that the runtime patching introduced by
    commit 2d1b2027626d ("powerpc: Fixup lwsync at runtime") continues to
    work properly with clang and the build no longer breaks.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1386
    Link: https://github.com/llvm/llvm-project/commit/62b5df7fe2b3fda1772befeda15598fbef96a614
    Link: https://lore.kernel.org/r/20210528182752.1852002-1-nathan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e7779b7470ef229b895c45e19d299cfa4902157b
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jun 22 09:15:35 2021 +0200

    fuse: reject internal errno
    
    commit 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 upstream.
    
    Don't allow userspace to report errors that could be kernel-internal.
    
    Reported-by: Anatoly Trosinenko <anatoly.trosinenko@gmail.com>
    Fixes: 334f485df85a ("[PATCH] FUSE - device functions")
    Cc: <stable@vger.kernel.org> # v2.6.14
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3941cf9b4b28fb787f98bbdae953ae433c19900e
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Jun 25 00:49:00 2021 +0200

    serial: mvebu-uart: fix calculation of clock divisor
    
    commit 9078204ca5c33ba20443a8623a41a68a9995a70d upstream.
    
    The clock divisor should be rounded to the closest value.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
    Cc: stable@vger.kernel.org # 0e4cf69ede87 ("serial: mvebu-uart: clarify the baud rate derivation")
    Link: https://lore.kernel.org/r/20210624224909.6350-2-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 424f497d9bdc24185bcaebc1f3f458a8d85e9d87
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Fri Nov 23 16:45:29 2018 +0100

    serial: mvebu-uart: clarify the baud rate derivation
    
    commit 0e4cf69ede8751d25f733cd7a6f954c5b505fa03 upstream.
    
    The current comment in ->set_baud_rate() is rather incomplete as it
    fails to describe what are the actual stages for the baudrate
    derivation. Replace this comment with something more explicit and
    close to the functional specification. Also adapt the variable names
    to it.
    
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b30af520403b56d123098f9569bf0ec110534709
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Fri Oct 4 13:00:24 2019 +0300

    bdi: Do not use freezable workqueue
    
    commit a2b90f11217790ec0964ba9c93a4abb369758c26 upstream.
    
    A removable block device, such as NVMe or SSD connected over Thunderbolt
    can be hot-removed any time including when the system is suspended. When
    device is hot-removed during suspend and the system gets resumed, kernel
    first resumes devices and then thaws the userspace including freezable
    workqueues. What happens in that case is that the NVMe driver notices
    that the device is unplugged and removes it from the system. This ends
    up calling bdi_unregister() for the gendisk which then schedules
    wb_workfn() to be run one more time.
    
    However, since the bdi_wq is still frozen flush_delayed_work() call in
    wb_shutdown() blocks forever halting system resume process. User sees
    this as hang as nothing is happening anymore.
    
    Triggering sysrq-w reveals this:
    
      Workqueue: nvme-wq nvme_remove_dead_ctrl_work [nvme]
      Call Trace:
       ? __schedule+0x2c5/0x630
       ? wait_for_completion+0xa4/0x120
       schedule+0x3e/0xc0
       schedule_timeout+0x1c9/0x320
       ? resched_curr+0x1f/0xd0
       ? wait_for_completion+0xa4/0x120
       wait_for_completion+0xc3/0x120
       ? wake_up_q+0x60/0x60
       __flush_work+0x131/0x1e0
       ? flush_workqueue_prep_pwqs+0x130/0x130
       bdi_unregister+0xb9/0x130
       del_gendisk+0x2d2/0x2e0
       nvme_ns_remove+0xed/0x110 [nvme_core]
       nvme_remove_namespaces+0x96/0xd0 [nvme_core]
       nvme_remove+0x5b/0x160 [nvme]
       pci_device_remove+0x36/0x90
       device_release_driver_internal+0xdf/0x1c0
       nvme_remove_dead_ctrl_work+0x14/0x30 [nvme]
       process_one_work+0x1c2/0x3f0
       worker_thread+0x48/0x3e0
       kthread+0x100/0x140
       ? current_work+0x30/0x30
       ? kthread_park+0x80/0x80
       ret_from_fork+0x35/0x40
    
    This is not limited to NVMes so exactly same issue can be reproduced by
    hot-removing SSD (over Thunderbolt) while the system is suspended.
    
    Prevent this from happening by removing WQ_FREEZABLE from bdi_wq.
    
    Reported-by: AceLan Kao <acelan.kao@canonical.com>
    Link: https://marc.info/?l=linux-kernel&m=138695698516487
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=204385
    Link: https://lore.kernel.org/lkml/20191002122136.GD2819@lahna.fi.intel.com/#t
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Cc: Macpaul Lin <macpaul.lin@mediatek.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aabde3a07a7900c5114c352103b8e9cd30302ee6
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu May 27 16:52:36 2021 -0700

    fscrypt: don't ignore minor_hash when hash is 0
    
    commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream.
    
    When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the
    minor_hash to 0 if the (major) hash is 0.
    
    This doesn't make sense because 0 is a valid hash code, so we shouldn't
    ignore the filesystem-provided minor_hash in that case.  Fix this by
    removing the special case for 'hash == 0'.
    
    This is an old bug that appears to have originated when the encryption
    code in ext4 and f2fs was moved into fs/crypto/.  The original ext4 and
    f2fs code passed the hash by pointer instead of by value.  So
    'if (hash)' actually made sense then, as it was checking whether a
    pointer was NULL.  But now the hashes are passed by value, and
    filesystems just pass 0 for any hashes they don't have.  There is no
    need to handle this any differently from the hashes actually being 0.
    
    It is difficult to reproduce this bug, as it only made a difference in
    the case where a filename's 32-bit major hash happened to be 0.
    However, it probably had the largest chance of causing problems on
    ubifs, since ubifs uses minor_hash to do lookups of no-key names, in
    addition to using it as a readdir cookie.  ext4 only uses minor_hash as
    a readdir cookie, and f2fs doesn't use minor_hash at all.
    
    Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto")
    Cc: <stable@vger.kernel.org> # v4.6+
    Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebfe50a690080e7fcccff503f4fdc8af120d3368
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Mon Jun 28 14:50:26 2021 -0700

    MIPS: set mips32r5 for virt extensions
    
    [ Upstream commit c994a3ec7ecc8bd2a837b2061e8a76eb8efc082b ]
    
    Clang's integrated assembler only accepts these instructions when the
    cpu is set to mips32r5. With this change, we can assemble
    malta_defconfig with Clang via `make LLVM_IAS=1`.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/763
    Reported-by: Dmitry Golovin <dima@golovin.in>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dd16e38e1531258d332b0fc7c247367f60c6c381
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Jun 28 16:13:42 2021 -0300

    sctp: add size validation when walking chunks
    
    [ Upstream commit 50619dbf8db77e98d821d615af4f634d08e22698 ]
    
    The first chunk in a packet is ensured to be present at the beginning of
    sctp_rcv(), as a packet needs to have at least 1 chunk. But the second
    one, may not be completely available and ch->length can be over
    uninitialized memory.
    
    Fix here is by only trying to walk on the next chunk if there is enough to
    hold at least the header, and then proceed with the ch->length validation
    that is already there.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7a03ebace4f9cd40d9cd9dd5fb2af558025583c
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Jun 28 16:13:41 2021 -0300

    sctp: validate from_addr_param return
    
    [ Upstream commit 0c5dc070ff3d6246d22ddd931f23a6266249e3db ]
    
    Ilja reported that, simply putting it, nothing was validating that
    from_addr_param functions were operating on initialized memory. That is,
    the parameter itself was being validated by sctp_walk_params, but it
    doesn't check for types and their specific sizes and it could be a 0-length
    one, causing from_addr_param to potentially work over the next parameter or
    even uninitialized memory.
    
    The fix here is to, in all calls to from_addr_param, check if enough space
    is there for the wanted IP address type.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 012a3944008fc774b1eae42be7e8dfc4ee2ab521
Author: Tim Jiang <tjiang@codeaurora.org>
Date:   Tue Jun 1 17:57:10 2021 +0800

    Bluetooth: btusb: fix bt fiwmare downloading failure issue for qca btsoc.
    
    [ Upstream commit 4f00bfb372674d586c4a261bfc595cbce101fbb6 ]
    
    This is btsoc timing issue, after host start to downloading bt firmware,
    ep2 need time to switch from function acl to function dfu, so host add
    20ms delay as workaround.
    
    Signed-off-by: Tim Jiang <tjiang@codeaurora.org>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78b03389d2773255ceaf051f2dca134b816d96f2
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri May 14 15:14:52 2021 +0800

    Bluetooth: Shutdown controller after workqueues are flushed or cancelled
    
    [ Upstream commit 0ea9fd001a14ebc294f112b0361a4e601551d508 ]
    
    Rfkill block and unblock Intel USB Bluetooth [8087:0026] may make it
    stops working:
    [  509.691509] Bluetooth: hci0: HCI reset during shutdown failed
    [  514.897584] Bluetooth: hci0: MSFT filter_enable is already on
    [  530.044751] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
    [  545.660350] usb 3-10: device descriptor read/64, error -110
    [  561.283530] usb 3-10: device descriptor read/64, error -110
    [  561.519682] usb 3-10: reset full-speed USB device number 5 using xhci_hcd
    [  566.686650] Bluetooth: hci0: unexpected event for opcode 0x0500
    [  568.752452] Bluetooth: hci0: urb 0000000096cd309b failed to resubmit (113)
    [  578.797955] Bluetooth: hci0: Failed to read MSFT supported features (-110)
    [  586.286565] Bluetooth: hci0: urb 00000000c522f633 failed to resubmit (113)
    [  596.215302] Bluetooth: hci0: Failed to read MSFT supported features (-110)
    
    Or kernel panics because other workqueues already freed skb:
    [ 2048.663763] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [ 2048.663775] #PF: supervisor read access in kernel mode
    [ 2048.663779] #PF: error_code(0x0000) - not-present page
    [ 2048.663782] PGD 0 P4D 0
    [ 2048.663787] Oops: 0000 [#1] SMP NOPTI
    [ 2048.663793] CPU: 3 PID: 4491 Comm: rfkill Tainted: G        W         5.13.0-rc1-next-20210510+ #20
    [ 2048.663799] Hardware name: HP HP EliteBook 850 G8 Notebook PC/8846, BIOS T76 Ver. 01.01.04 12/02/2020
    [ 2048.663801] RIP: 0010:__skb_ext_put+0x6/0x50
    [ 2048.663814] Code: 8b 1b 48 85 db 75 db 5b 41 5c 5d c3 be 01 00 00 00 e8 de 13 c0 ff eb e7 be 02 00 00 00 e8 d2 13 c0 ff eb db 0f 1f 44 00 00 55 <8b> 07 48 89 e5 83 f8 01 74 14 b8 ff ff ff ff f0 0f c1
    07 83 f8 01
    [ 2048.663819] RSP: 0018:ffffc1d105b6fd80 EFLAGS: 00010286
    [ 2048.663824] RAX: 0000000000000000 RBX: ffff9d9ac5649000 RCX: 0000000000000000
    [ 2048.663827] RDX: ffffffffc0d1daf6 RSI: 0000000000000206 RDI: 0000000000000000
    [ 2048.663830] RBP: ffffc1d105b6fd98 R08: 0000000000000001 R09: ffff9d9ace8ceac0
    [ 2048.663834] R10: ffff9d9ace8ceac0 R11: 0000000000000001 R12: ffff9d9ac5649000
    [ 2048.663838] R13: 0000000000000000 R14: 00007ffe0354d650 R15: 0000000000000000
    [ 2048.663843] FS:  00007fe02ab19740(0000) GS:ffff9d9e5f8c0000(0000) knlGS:0000000000000000
    [ 2048.663849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 2048.663853] CR2: 0000000000000000 CR3: 0000000111a52004 CR4: 0000000000770ee0
    [ 2048.663856] PKRU: 55555554
    [ 2048.663859] Call Trace:
    [ 2048.663865]  ? skb_release_head_state+0x5e/0x80
    [ 2048.663873]  kfree_skb+0x2f/0xb0
    [ 2048.663881]  btusb_shutdown_intel_new+0x36/0x60 [btusb]
    [ 2048.663905]  hci_dev_do_close+0x48c/0x5e0 [bluetooth]
    [ 2048.663954]  ? __cond_resched+0x1a/0x50
    [ 2048.663962]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
    [ 2048.664007]  rfkill_set_block+0x98/0x170
    [ 2048.664016]  rfkill_fop_write+0x136/0x1e0
    [ 2048.664022]  vfs_write+0xc7/0x260
    [ 2048.664030]  ksys_write+0xb1/0xe0
    [ 2048.664035]  ? exit_to_user_mode_prepare+0x37/0x1c0
    [ 2048.664042]  __x64_sys_write+0x1a/0x20
    [ 2048.664048]  do_syscall_64+0x40/0xb0
    [ 2048.664055]  entry_SYSCALL_64_after_hwframe+0x44/0xae
    [ 2048.664060] RIP: 0033:0x7fe02ac23c27
    [ 2048.664066] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
    [ 2048.664070] RSP: 002b:00007ffe0354d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ 2048.664075] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fe02ac23c27
    [ 2048.664078] RDX: 0000000000000008 RSI: 00007ffe0354d650 RDI: 0000000000000003
    [ 2048.664081] RBP: 0000000000000000 R08: 0000559b05998440 R09: 0000559b05998440
    [ 2048.664084] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003
    [ 2048.664086] R13: 0000000000000000 R14: ffffffff00000000 R15: 00000000ffffffff
    
    So move the shutdown callback to a place where workqueues are either
    flushed or cancelled to resolve the issue.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06de654ddcbfcd5e486dc7f44f9478b66d6e7a5b
Author: Yu Liu <yudiliu@google.com>
Date:   Mon Apr 19 16:53:30 2021 -0700

    Bluetooth: Fix the HCI to MGMT status conversion table
    
    [ Upstream commit 4ef36a52b0e47c80bbfd69c0cce61c7ae9f541ed ]
    
    0x2B, 0x31 and 0x33 are reserved for future use but were not present in
    the HCI to MGMT conversion table, this caused the conversion to be
    incorrect for the HCI status code greater than 0x2A.
    
    Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
    Signed-off-by: Yu Liu <yudiliu@google.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4893c938f2a140a74be91779e45e4a7fa111198f
Author: Gerd Rausch <gerd.rausch@oracle.com>
Date:   Thu Jun 24 11:55:31 2021 -0700

    RDMA/cma: Fix rdma_resolve_route() memory leak
    
    [ Upstream commit 74f160ead74bfe5f2b38afb4fcf86189f9ff40c9 ]
    
    Fix a memory leak when "mda_resolve_route() is called more than once on
    the same "rdma_cm_id".
    
    This is possible if cma_query_handler() triggers the
    RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and
    allows rdma_resolve_route() to be called again.
    
    Link: https://lore.kernel.org/r/f6662b7b-bdb7-2706-1e12-47c61d3474b6@oracle.com
    Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a847a5e25692a8d4637881f00d0453221ca086ef
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Wed Jun 23 14:44:38 2021 -0700

    net: ip: avoid OOM kills with large UDP sends over loopback
    
    [ Upstream commit 6d123b81ac615072a8525c13c6c41b695270a15d ]
    
    Dave observed number of machines hitting OOM on the UDP send
    path. The workload seems to be sending large UDP packets over
    loopback. Since loopback has MTU of 64k kernel will try to
    allocate an skb with up to 64k of head space. This has a good
    chance of failing under memory pressure. What's worse if
    the message length is <32k the allocation may trigger an
    OOM killer.
    
    This is entirely avoidable, we can use an skb with page frags.
    
    af_unix solves a similar problem by limiting the head
    length to SKB_MAX_ALLOC. This seems like a good and simple
    approach. It means that UDP messages > 16kB will now
    use fragments if underlying device supports SG, if extra
    allocator pressure causes regressions in real workloads
    we can switch to trying the large allocation first and
    falling back.
    
    v4: pre-calculate all the additions to alloclen so
        we can be sure it won't go over order-2
    
    Reported-by: Dave Jones <dsj@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cd352fc2db99c186276c8291850de75de6dbadc
Author: Sean Young <sean@mess.org>
Date:   Wed Jun 23 22:37:54 2021 +0100

    media, bpf: Do not copy more entries than user space requested
    
    [ Upstream commit 647d446d66e493d23ca1047fa8492b0269674530 ]
    
    The syscall bpf(BPF_PROG_QUERY, &attr) should use the prog_cnt field to
    see how many entries user space provided and return ENOSPC if there are
    more programs than that. Before this patch, this is not checked and
    ENOSPC is never returned.
    
    Note that one lirc device is limited to 64 bpf programs, and user space
    I'm aware of -- ir-keytable -- always gives enough space for 64 entries
    already. However, we should not copy program ids than are requested.
    
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Link: https://lore.kernel.org/bpf/20210623213754.632-1-sean@mess.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 99594d19177d95fc865b3ddc5bcb1c29df118933
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Thu Apr 22 15:00:32 2021 -0500

    wireless: wext-spy: Fix out-of-bounds warning
    
    [ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ]
    
    Fix the following out-of-bounds warning:
    
    net/wireless/wext-spy.c:178:2: warning: 'memcpy' offset [25, 28] from the object at 'threshold' is out of the bounds of referenced subobject 'low' with type 'struct iw_quality' at offset 20 [-Warray-bounds]
    
    The problem is that the original code is trying to copy data into a
    couple of struct members adjacent to each other in a single call to
    memcpy(). This causes a legitimate compiler warning because memcpy()
    overruns the length of &threshold.low and &spydata->spy_thr_low. As
    these are just a couple of struct members, fix this by using direct
    assignments, instead of memcpy().
    
    This helps with the ongoing efforts to globally enable -Warray-bounds
    and get us closer to being able to tighten the FORTIFY_SOURCE routines
    on memcpy().
    
    Link: https://github.com/KSPP/linux/issues/109
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6a722d24bec1f50df07c9f83ee11d06c7bd1b8a8
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Mon Jun 21 17:32:36 2021 +0200

    sfc: error code if SRIOV cannot be disabled
    
    [ Upstream commit 1ebe4feb8b442884f5a28d2437040096723dd1ea ]
    
    If SRIOV cannot be disabled during device removal or module unloading,
    return error code so it can be logged properly in the calling function.
    
    Note that this can only happen if any VF is currently attached to a
    guest using Xen, but not with vfio/KVM. Despite that in that case the
    VFs won't work properly with PF removed and/or the module unloaded, I
    have let it as is because I don't know what side effects may have
    changing it, and also it seems to be the same that other drivers are
    doing in this situation.
    
    In the case of being called during SRIOV reconfiguration, the behavior
    hasn't changed because the function is called with force=false.
    
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f734b8de9848ef1f3a43270c3538730409682c8
Author: Íñigo Huguet <ihuguet@redhat.com>
Date:   Mon Jun 21 17:32:35 2021 +0200

    sfc: avoid double pci_remove of VFs
    
    [ Upstream commit 45423cff1db66cf0993e8a9bd0ac93e740149e49 ]
    
    If pci_remove was called for a PF with VFs, the removal of the VFs was
    called twice from efx_ef10_sriov_fini: one directly with pci_driver->remove
    and another implicit by calling pci_disable_sriov, which also perform
    the VFs remove. This was leading to crashing the kernel on the second
    attempt.
    
    Given that pci_disable_sriov already calls to pci remove function, get
    rid of the direct call to pci_driver->remove from the driver.
    
    2 different ways to trigger the bug:
    - Create one or more VFs, then attach the PF to a virtual machine (at
      least with qemu/KVM)
    - Create one or more VFs, then remove the PF with:
      echo 1 > /sys/bus/pci/devices/PF_PCI_ID/remove
    
    Removing sfc module does not trigger the error, at least for me, because
    it removes the VF first, and then the PF.
    
    Example of a log with the error:
        list_del corruption, ffff967fd20a8ad0->next is LIST_POISON1 (dead000000000100)
        ------------[ cut here ]------------
        kernel BUG at lib/list_debug.c:47!
        [...trimmed...]
        RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
        [...trimmed...]
        Call Trace:
        efx_dissociate+0x1f/0x140 [sfc]
        efx_pci_remove+0x27/0x150 [sfc]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x103/0x1f0
        pci_stop_bus_device+0x69/0x90
        pci_stop_and_remove_bus_device+0xe/0x20
        pci_iov_remove_virtfn+0xba/0x120
        sriov_disable+0x2f/0xe0
        efx_ef10_pci_sriov_disable+0x52/0x80 [sfc]
        ? pcie_aer_is_native+0x12/0x40
        efx_ef10_sriov_fini+0x72/0x110 [sfc]
        efx_pci_remove+0x62/0x150 [sfc]
        pci_device_remove+0x3b/0xc0
        device_release_driver_internal+0x103/0x1f0
        unbind_store+0xf6/0x130
        kernfs_fop_write+0x116/0x190
        vfs_write+0xa5/0x1a0
        ksys_write+0x4f/0xb0
        do_syscall_64+0x5b/0x1a0
        entry_SYSCALL_64_after_hwframe+0x65/0xca
    
    Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b1abc4e97cf14d14c30fcd2055663af53d92e2d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jun 18 11:01:16 2021 +0300

    iwlwifi: pcie: free IML DMA memory allocation
    
    [ Upstream commit 310f60f53a86eba680d9bc20a371e13b06a5f903 ]
    
    In the case of gen3 devices with image loader (IML) support,
    we were leaking the IML DMA allocation and never freeing it.
    Fix that.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20210618105614.07e117dbedb7.I7bb9ebbe0617656986c2a598ea5e827b533bd3b9@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c536e805fe4771ea4bf098e23e0364af5badc46
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sat Jun 12 14:32:38 2021 +0300

    iwlwifi: mvm: don't change band on bound PHY contexts
    
    [ Upstream commit 8835a64f74c46baebfc946cd5a2c861b866ebcee ]
    
    When we have a P2P Device active, we attempt to only change the
    PHY context it uses when we get a new remain-on-channel, if the
    P2P Device is the only user of the PHY context.
    
    This is fine if we're switching within a band, but if we're
    switching bands then the switch implies a removal and re-add
    of the PHY context, which isn't permitted by the firmware while
    it's bound to an interface.
    
    Fix the code to skip the unbind/release/... cycle only if the
    band doesn't change (or we have old devices that can switch the
    band on the fly as well.)
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Link: https://lore.kernel.org/r/iwlwifi.20210612142637.e9ac313f70f3.I713b9d109957df7e7d9ed0861d5377ce3f8fccd3@changeid
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92aa20a768b4a1b30242801c39d61b51c6127ffe
Author: Xiao Yang <yangx.jy@fujitsu.com>
Date:   Mon Jun 21 15:14:56 2021 +0800

    RDMA/rxe: Don't overwrite errno from ib_umem_get()
    
    [ Upstream commit 20ec0a6d6016aa28b9b3299be18baef1a0f91cd2 ]
    
    rxe_mr_init_user() always returns the fixed -EINVAL when ib_umem_get()
    fails so it's hard for user to know which actual error happens in
    ib_umem_get(). For example, ib_umem_get() will return -EOPNOTSUPP when
    trying to pin pages on a DAX file.
    
    Return actual error as mlx4/mlx5 does.
    
    Link: https://lore.kernel.org/r/20210621071456.4259-1-ice_yangxiao@163.com
    Signed-off-by: Xiao Yang <yangx.jy@fujitsu.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0ea3919ffdb946390669b89e2437e0a70e8581be
Author: Longpeng(Mike) <longpeng2@huawei.com>
Date:   Mon Jun 21 14:26:01 2021 +0800

    vsock: notify server to shutdown when client has pending signal
    
    [ Upstream commit c7ff9cff70601ea19245d997bb977344663434c7 ]
    
    The client's sk_state will be set to TCP_ESTABLISHED if the server
    replay the client's connect request.
    
    However, if the client has pending signal, its sk_state will be set
    to TCP_CLOSE without notify the server, so the server will hold the
    corrupt connection.
    
                client                        server
    
    1. sk_state=TCP_SYN_SENT         |
    2. call ->connect()              |
    3. wait reply                    |
                                     | 4. sk_state=TCP_ESTABLISHED
                                     | 5. insert to connected list
                                     | 6. reply to the client
    7. sk_state=TCP_ESTABLISHED      |
    8. insert to connected list      |
    9. *signal pending* <--------------------- the user kill client
    10. sk_state=TCP_CLOSE           |
    client is exiting...             |
    11. call ->release()             |
         virtio_transport_close
          if (!(sk->sk_state == TCP_ESTABLISHED ||
                  sk->sk_state == TCP_CLOSING))
                    return true; *return at here, the server cannot notice the connection is corrupt*
    
    So the client should notify the peer in this case.
    
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Jorgen Hansen <jhansen@vmware.com>
    Cc: Norbert Slusarek <nslusarek@gmx.net>
    Cc: Andra Paraschiv <andraprs@amazon.com>
    Cc: Colin Ian King <colin.king@canonical.com>
    Cc: David Brazdil <dbrazdil@google.com>
    Cc: Alexander Popov <alex.popov@linux.com>
    Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lkml.org/lkml/2021/5/17/418
    Signed-off-by: lixianming <lixianming5@huawei.com>
    Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e34c635cf0344be10aca8a104ba509c00704d03c
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sun Jun 20 15:24:15 2021 +0000

    atm: nicstar: register the interrupt handler in the right place
    
    [ Upstream commit 70b639dc41ad499384e41e106fce72e36805c9f2 ]
    
    Because the error handling is sequential, the application of resources
    should be carried out in the order of error handling, so the operation
    of registering the interrupt handler should be put in front, so as not
    to free the unregistered interrupt handler during error handling.
    
    This log reveals it:
    
    [    3.438724] Trying to free already-free IRQ 23
    [    3.439060] WARNING: CPU: 5 PID: 1 at kernel/irq/manage.c:1825 free_irq+0xfb/0x480
    [    3.440039] Modules linked in:
    [    3.440257] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #142
    [    3.440793] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [    3.441561] RIP: 0010:free_irq+0xfb/0x480
    [    3.441845] Code: 6e 08 74 6f 4d 89 f4 e8 c3 78 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 b4 78 09 00 8b 75 c8 48 c7 c7 a0 ac d5 85 e8 95 d7 f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 87 c5 90 03 48 8b 43 40 4c 8b a0 80
    [    3.443121] RSP: 0000:ffffc90000017b50 EFLAGS: 00010086
    [    3.443483] RAX: 0000000000000000 RBX: ffff888107c6f000 RCX: 0000000000000000
    [    3.443972] RDX: 0000000000000000 RSI: ffffffff8123f301 RDI: 00000000ffffffff
    [    3.444462] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000003
    [    3.444950] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
    [    3.444994] R13: ffff888107dc0000 R14: ffff888104f6bf00 R15: ffff888107c6f0a8
    [    3.444994] FS:  0000000000000000(0000) GS:ffff88817bd40000(0000) knlGS:0000000000000000
    [    3.444994] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    3.444994] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
    [    3.444994] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [    3.444994] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [    3.444994] Call Trace:
    [    3.444994]  ns_init_card_error+0x18e/0x250
    [    3.444994]  nicstar_init_one+0x10d2/0x1130
    [    3.444994]  local_pci_probe+0x4a/0xb0
    [    3.444994]  pci_device_probe+0x126/0x1d0
    [    3.444994]  ? pci_device_remove+0x100/0x100
    [    3.444994]  really_probe+0x27e/0x650
    [    3.444994]  driver_probe_device+0x84/0x1d0
    [    3.444994]  ? mutex_lock_nested+0x16/0x20
    [    3.444994]  device_driver_attach+0x63/0x70
    [    3.444994]  __driver_attach+0x117/0x1a0
    [    3.444994]  ? device_driver_attach+0x70/0x70
    [    3.444994]  bus_for_each_dev+0xb6/0x110
    [    3.444994]  ? rdinit_setup+0x40/0x40
    [    3.444994]  driver_attach+0x22/0x30
    [    3.444994]  bus_add_driver+0x1e6/0x2a0
    [    3.444994]  driver_register+0xa4/0x180
    [    3.444994]  __pci_register_driver+0x77/0x80
    [    3.444994]  ? uPD98402_module_init+0xd/0xd
    [    3.444994]  nicstar_init+0x1f/0x75
    [    3.444994]  do_one_initcall+0x7a/0x3d0
    [    3.444994]  ? rdinit_setup+0x40/0x40
    [    3.444994]  ? rcu_read_lock_sched_held+0x4a/0x70
    [    3.444994]  kernel_init_freeable+0x2a7/0x2f9
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  kernel_init+0x13/0x180
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  ret_from_fork+0x1f/0x30
    [    3.444994] Kernel panic - not syncing: panic_on_warn set ...
    [    3.444994] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #142
    [    3.444994] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [    3.444994] Call Trace:
    [    3.444994]  dump_stack+0xba/0xf5
    [    3.444994]  ? free_irq+0xfb/0x480
    [    3.444994]  panic+0x155/0x3ed
    [    3.444994]  ? __warn+0xed/0x150
    [    3.444994]  ? free_irq+0xfb/0x480
    [    3.444994]  __warn+0x103/0x150
    [    3.444994]  ? free_irq+0xfb/0x480
    [    3.444994]  report_bug+0x119/0x1c0
    [    3.444994]  handle_bug+0x3b/0x80
    [    3.444994]  exc_invalid_op+0x18/0x70
    [    3.444994]  asm_exc_invalid_op+0x12/0x20
    [    3.444994] RIP: 0010:free_irq+0xfb/0x480
    [    3.444994] Code: 6e 08 74 6f 4d 89 f4 e8 c3 78 09 00 4d 8b 74 24 18 4d 85 f6 75 e3 e8 b4 78 09 00 8b 75 c8 48 c7 c7 a0 ac d5 85 e8 95 d7 f5 ff <0f> 0b 48 8b 75 c0 4c 89 ff e8 87 c5 90 03 48 8b 43 40 4c 8b a0 80
    [    3.444994] RSP: 0000:ffffc90000017b50 EFLAGS: 00010086
    [    3.444994] RAX: 0000000000000000 RBX: ffff888107c6f000 RCX: 0000000000000000
    [    3.444994] RDX: 0000000000000000 RSI: ffffffff8123f301 RDI: 00000000ffffffff
    [    3.444994] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000003
    [    3.444994] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
    [    3.444994] R13: ffff888107dc0000 R14: ffff888104f6bf00 R15: ffff888107c6f0a8
    [    3.444994]  ? vprintk_func+0x71/0x110
    [    3.444994]  ns_init_card_error+0x18e/0x250
    [    3.444994]  nicstar_init_one+0x10d2/0x1130
    [    3.444994]  local_pci_probe+0x4a/0xb0
    [    3.444994]  pci_device_probe+0x126/0x1d0
    [    3.444994]  ? pci_device_remove+0x100/0x100
    [    3.444994]  really_probe+0x27e/0x650
    [    3.444994]  driver_probe_device+0x84/0x1d0
    [    3.444994]  ? mutex_lock_nested+0x16/0x20
    [    3.444994]  device_driver_attach+0x63/0x70
    [    3.444994]  __driver_attach+0x117/0x1a0
    [    3.444994]  ? device_driver_attach+0x70/0x70
    [    3.444994]  bus_for_each_dev+0xb6/0x110
    [    3.444994]  ? rdinit_setup+0x40/0x40
    [    3.444994]  driver_attach+0x22/0x30
    [    3.444994]  bus_add_driver+0x1e6/0x2a0
    [    3.444994]  driver_register+0xa4/0x180
    [    3.444994]  __pci_register_driver+0x77/0x80
    [    3.444994]  ? uPD98402_module_init+0xd/0xd
    [    3.444994]  nicstar_init+0x1f/0x75
    [    3.444994]  do_one_initcall+0x7a/0x3d0
    [    3.444994]  ? rdinit_setup+0x40/0x40
    [    3.444994]  ? rcu_read_lock_sched_held+0x4a/0x70
    [    3.444994]  kernel_init_freeable+0x2a7/0x2f9
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  kernel_init+0x13/0x180
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  ? rest_init+0x2c0/0x2c0
    [    3.444994]  ret_from_fork+0x1f/0x30
    [    3.444994] Dumping ftrace buffer:
    [    3.444994]    (ftrace buffer empty)
    [    3.444994] Kernel Offset: disabled
    [    3.444994] Rebooting in 1 seconds..
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a618f815f36252d07170cbbc15a0115399dd9998
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Sun Jun 20 15:24:14 2021 +0000

    atm: nicstar: use 'dma_free_coherent' instead of 'kfree'
    
    [ Upstream commit 6a1e5a4af17e440dd82a58a2c5f40ff17a82b722 ]
    
    When 'nicstar_init_one' fails, 'ns_init_card_error' will be executed for
    error handling, but the correct memory free function should be used,
    otherwise it will cause an error. Since 'card->rsq.org' and
    'card->tsq.org' are allocated using 'dma_alloc_coherent' function, they
    should be freed using 'dma_free_coherent'.
    
    Fix this by using 'dma_free_coherent' instead of 'kfree'
    
    This log reveals it:
    
    [    3.440294] kernel BUG at mm/slub.c:4206!
    [    3.441059] invalid opcode: 0000 [#1] PREEMPT SMP PTI
    [    3.441430] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.12.4-g70e7f0549188-dirty #141
    [    3.441986] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [    3.442780] RIP: 0010:kfree+0x26a/0x300
    [    3.443065] Code: e8 3a c3 b9 ff e9 d6 fd ff ff 49 8b 45 00 31 db a9 00 00 01 00 75 4d 49 8b 45 00 a9 00 00 01 00 75 0a 49 8b 45 08 a8 01 75 02 <0f> 0b 89 d9 b8 00 10 00 00 be 06 00 00 00 48 d3 e0 f7 d8 48 63 d0
    [    3.443396] RSP: 0000:ffffc90000017b70 EFLAGS: 00010246
    [    3.443396] RAX: dead000000000100 RBX: 0000000000000000 RCX: 0000000000000000
    [    3.443396] RDX: 0000000000000000 RSI: ffffffff85d3df94 RDI: ffffffff85df38e6
    [    3.443396] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000001
    [    3.443396] R10: 0000000000000000 R11: 0000000000000001 R12: ffff888107dc0000
    [    3.443396] R13: ffffea00001f0100 R14: ffff888101a8bf00 R15: ffff888107dc0160
    [    3.443396] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
    [    3.443396] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    3.443396] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
    [    3.443396] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [    3.443396] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [    3.443396] Call Trace:
    [    3.443396]  ns_init_card_error+0x12c/0x220
    [    3.443396]  nicstar_init_one+0x10d2/0x1130
    [    3.443396]  local_pci_probe+0x4a/0xb0
    [    3.443396]  pci_device_probe+0x126/0x1d0
    [    3.443396]  ? pci_device_remove+0x100/0x100
    [    3.443396]  really_probe+0x27e/0x650
    [    3.443396]  driver_probe_device+0x84/0x1d0
    [    3.443396]  ? mutex_lock_nested+0x16/0x20
    [    3.443396]  device_driver_attach+0x63/0x70
    [    3.443396]  __driver_attach+0x117/0x1a0
    [    3.443396]  ? device_driver_attach+0x70/0x70
    [    3.443396]  bus_for_each_dev+0xb6/0x110
    [    3.443396]  ? rdinit_setup+0x40/0x40
    [    3.443396]  driver_attach+0x22/0x30
    [    3.443396]  bus_add_driver+0x1e6/0x2a0
    [    3.443396]  driver_register+0xa4/0x180
    [    3.443396]  __pci_register_driver+0x77/0x80
    [    3.443396]  ? uPD98402_module_init+0xd/0xd
    [    3.443396]  nicstar_init+0x1f/0x75
    [    3.443396]  do_one_initcall+0x7a/0x3d0
    [    3.443396]  ? rdinit_setup+0x40/0x40
    [    3.443396]  ? rcu_read_lock_sched_held+0x4a/0x70
    [    3.443396]  kernel_init_freeable+0x2a7/0x2f9
    [    3.443396]  ? rest_init+0x2c0/0x2c0
    [    3.443396]  kernel_init+0x13/0x180
    [    3.443396]  ? rest_init+0x2c0/0x2c0
    [    3.443396]  ? rest_init+0x2c0/0x2c0
    [    3.443396]  ret_from_fork+0x1f/0x30
    [    3.443396] Modules linked in:
    [    3.443396] Dumping ftrace buffer:
    [    3.443396]    (ftrace buffer empty)
    [    3.458593] ---[ end trace 3c6f8f0d8ef59bcd ]---
    [    3.458922] RIP: 0010:kfree+0x26a/0x300
    [    3.459198] Code: e8 3a c3 b9 ff e9 d6 fd ff ff 49 8b 45 00 31 db a9 00 00 01 00 75 4d 49 8b 45 00 a9 00 00 01 00 75 0a 49 8b 45 08 a8 01 75 02 <0f> 0b 89 d9 b8 00 10 00 00 be 06 00 00 00 48 d3 e0 f7 d8 48 63 d0
    [    3.460499] RSP: 0000:ffffc90000017b70 EFLAGS: 00010246
    [    3.460870] RAX: dead000000000100 RBX: 0000000000000000 RCX: 0000000000000000
    [    3.461371] RDX: 0000000000000000 RSI: ffffffff85d3df94 RDI: ffffffff85df38e6
    [    3.461873] RBP: ffffc90000017b90 R08: 0000000000000001 R09: 0000000000000001
    [    3.462372] R10: 0000000000000000 R11: 0000000000000001 R12: ffff888107dc0000
    [    3.462871] R13: ffffea00001f0100 R14: ffff888101a8bf00 R15: ffff888107dc0160
    [    3.463368] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000
    [    3.463949] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    3.464356] CR2: 0000000000000000 CR3: 000000000642e000 CR4: 00000000000006e0
    [    3.464856] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [    3.465356] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [    3.465860] Kernel panic - not syncing: Fatal exception
    [    3.466370] Dumping ftrace buffer:
    [    3.466616]    (ftrace buffer empty)
    [    3.466871] Kernel Offset: disabled
    [    3.467122] Rebooting in 1 seconds..
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 68046cc531577b8f0ebe67ccf18b9c70106d7937
Author: Huang Pei <huangpei@loongson.cn>
Date:   Fri Jun 11 15:09:46 2021 +0800

    MIPS: add PMD table accounting into MIPS'pmd_alloc_one
    
    [ Upstream commit ed914d48b6a1040d1039d371b56273d422c0081e ]
    
    This fixes Page Table accounting bug.
    
    MIPS is the ONLY arch just defining __HAVE_ARCH_PMD_ALLOC_ONE alone.
    Since commit b2b29d6d011944 (mm: account PMD tables like PTE tables),
    "pmd_free" in asm-generic with PMD table accounting and "pmd_alloc_one"
    in MIPS without PMD table accounting causes PageTable accounting number
    negative, which read by global_zone_page_state(), always returns 0.
    
    Signed-off-by: Huang Pei <huangpei@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d1b71f247486c73b3afc747d31f97c2159ec3f2e
Author: Pascal Terjan <pterjan@google.com>
Date:   Sat Apr 24 18:29:59 2021 +0100

    rtl8xxxu: Fix device info for RTL8192EU devices
    
    [ Upstream commit c240b044edefa3c3af4014a4030e017dd95b59a1 ]
    
    Based on 2001:3319 and 2357:0109 which I used to test the fix and
    0bda:818b and 2357:0108 for which I found efuse dumps online.
    
    == 2357:0109 ==
    === Before ===
    Vendor: Realtek
    Product: \x03802.11n NI
    Serial:
    === After ===
    Vendor: Realtek
    Product: 802.11n NIC
    Serial not available.
    
    == 2001:3319 ==
    === Before ===
    Vendor: Realtek
    Product: Wireless N
    Serial: no USB Adap
    === After ===
    Vendor: Realtek
    Product: Wireless N Nano USB Adapter
    Serial not available.
    
    Signed-off-by: Pascal Terjan <pterjan@google.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210424172959.1559890-1-pterjan@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cba5008c8581a5cdebf62b1d4699148c606ab423
Author: Jian Shen <shenjian15@huawei.com>
Date:   Thu Jun 17 11:37:11 2021 +0800

    net: fix mistake path for netdev_features_strings
    
    [ Upstream commit 2d8ea148e553e1dd4e80a87741abdfb229e2b323 ]
    
    Th_strings arrays netdev_features_strings, tunable_strings, and
    phy_tunable_strings has been moved to file net/ethtool/common.c.
    So fixes the comment.
    
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c1ee7d54b08150ed5035071c60d8425ca60815db
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 11:05:14 2021 +0800

    cw1200: add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit dd778f89225cd258e8f0fed2b7256124982c8bb5 ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1620788714-14300-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 115103f6e3f1c26c473766c16439c7c8b235529a
Author: Lee Gibson <leegib@gmail.com>
Date:   Wed Apr 28 12:55:08 2021 +0100

    wl1251: Fix possible buffer overflow in wl1251_cmd_scan
    
    [ Upstream commit d10a87a3535cce2b890897914f5d0d83df669c63 ]
    
    Function wl1251_cmd_scan calls memcpy without checking the length.
    Harden by checking the length is within the maximum allowed size.
    
    Signed-off-by: Lee Gibson <leegib@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210428115508.25624-1-leegib@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ad41656f8e27c1547bbb7cb9230eef8a80ba2aa
Author: Tony Lindgren <tony@atomide.com>
Date:   Thu Jun 3 09:28:14 2021 +0300

    wlcore/wl12xx: Fix wl12xx get_mac error if device is in ELP
    
    [ Upstream commit 11ef6bc846dcdce838f0b00c5f6a562c57e5d43b ]
    
    At least on wl12xx, reading the MAC after boot can fail with a warning
    at drivers/net/wireless/ti/wlcore/sdio.c:78 wl12xx_sdio_raw_read.
    The failed call comes from wl12xx_get_mac() that wlcore_nvs_cb() calls
    after request_firmware_work_func().
    
    After the error, no wireless interface is created. Reloading the wl12xx
    module makes the interface work.
    
    Turns out the wlan controller can be in a low-power ELP state after the
    boot from the bootloader or kexec, and needs to be woken up first.
    
    Let's wake the hardware and add a sleep after that similar to
    wl12xx_pre_boot() is already doing.
    
    Note that a similar issue could exist for wl18xx, but I have not seen it
    so far. And a search for wl18xx_get_mac and wl12xx_sdio_raw_read did not
    produce similar errors.
    
    Cc: Carl Philipp Klemm <philipp@uvos.xyz>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210603062814.19464-1-tony@atomide.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b559f417a1aa8715fe040322b1efcb164aea9851
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Mon Jun 7 15:21:49 2021 +0200

    xfrm: Fix error reporting in xfrm_state_construct.
    
    [ Upstream commit 6fd06963fa74197103cdbb4b494763127b3f2f34 ]
    
    When memory allocation for XFRMA_ENCAP or XFRMA_COADDR fails,
    the error will not be reported because the -ENOMEM assignment
    to the err variable is overwritten before. Fix this by moving
    these two in front of the function so that memory allocation
    failures will be reported.
    
    Reported-by: Tobias Brunner <tobias@strongswan.org>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0881aaa1bca6c228871f141b52500fe738f1909a
Author: Minchan Kim <minchan@kernel.org>
Date:   Wed Jun 9 09:37:17 2021 -0700

    selinux: use __GFP_NOWARN with GFP_NOWAIT in the AVC
    
    [ Upstream commit 648f2c6100cfa18e7dfe43bc0b9c3b73560d623c ]
    
    In the field, we have seen lots of allocation failure from the call
    path below.
    
    06-03 13:29:12.999 1010315 31557 31557 W Binder  : 31542_2: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=background,mems_allowed=0
    ...
    ...
    06-03 13:29:12.999 1010315 31557 31557 W Call trace:
    06-03 13:29:12.999 1010315 31557 31557 W         : dump_backtrace.cfi_jt+0x0/0x8
    06-03 13:29:12.999 1010315 31557 31557 W         : dump_stack+0xc8/0x14c
    06-03 13:29:12.999 1010315 31557 31557 W         : warn_alloc+0x158/0x1c8
    06-03 13:29:12.999 1010315 31557 31557 W         : __alloc_pages_slowpath+0x9d8/0xb80
    06-03 13:29:12.999 1010315 31557 31557 W         : __alloc_pages_nodemask+0x1c4/0x430
    06-03 13:29:12.999 1010315 31557 31557 W         : allocate_slab+0xb4/0x390
    06-03 13:29:12.999 1010315 31557 31557 W         : ___slab_alloc+0x12c/0x3a4
    06-03 13:29:12.999 1010315 31557 31557 W         : kmem_cache_alloc+0x358/0x5e4
    06-03 13:29:12.999 1010315 31557 31557 W         : avc_alloc_node+0x30/0x184
    06-03 13:29:12.999 1010315 31557 31557 W         : avc_update_node+0x54/0x4f0
    06-03 13:29:12.999 1010315 31557 31557 W         : avc_has_extended_perms+0x1a4/0x460
    06-03 13:29:12.999 1010315 31557 31557 W         : selinux_file_ioctl+0x320/0x3d0
    06-03 13:29:12.999 1010315 31557 31557 W         : __arm64_sys_ioctl+0xec/0x1fc
    06-03 13:29:12.999 1010315 31557 31557 W         : el0_svc_common+0xc0/0x24c
    06-03 13:29:12.999 1010315 31557 31557 W         : el0_svc+0x28/0x88
    06-03 13:29:12.999 1010315 31557 31557 W         : el0_sync_handler+0x8c/0xf0
    06-03 13:29:12.999 1010315 31557 31557 W         : el0_sync+0x1a4/0x1c0
    ..
    ..
    06-03 13:29:12.999 1010315 31557 31557 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:12.999 1010315 31557 31557 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:12.999 1010315 31557 31557 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:12.999 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:12.999 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:12.999 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:12.999 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:12.999 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:12.999 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:12.999 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:12.999 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:12.999 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:13.000 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:13.000 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:13.000 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:13.000 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:13.000 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:13.000 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:13.000 1010161 10686 10686 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:13.000 1010161 10686 10686 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:13.000 1010161 10686 10686 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:13.000 10230 30892 30892 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:13.000 10230 30892 30892 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    06-03 13:29:13.000 10230 30892 30892 W node 0  : slabs: 57, objs: 2907, free: 0
    06-03 13:29:13.000 10230 30892 30892 W SLUB    : Unable to allocate memory on node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
    06-03 13:29:13.000 10230 30892 30892 W cache   : avc_node, object size: 72, buffer size: 80, default order: 0, min order: 0
    
    Based on [1], selinux is tolerate for failure of memory allocation.
    Then, use __GFP_NOWARN together.
    
    [1] 476accbe2f6e ("selinux: use GFP_NOWAIT in the AVC kmem_caches")
    
    Signed-off-by: Minchan Kim <minchan@kernel.org>
    [PM: subj fix, line wraps, normalized commit refs]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ad9a63eb8ac0c0d8b7b13bb8d1c516e72e58eb3b
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Jun 10 16:02:43 2021 +0800

    fjes: check return value after calling platform_get_resource()
    
    [ Upstream commit f18c11812c949553d2b2481ecaa274dd51bed1e7 ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d4ba2600616a7c5e6b44f2319a808c465475c0f
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Jun 7 22:55:21 2021 +0800

    net: micrel: check return value after calling platform_get_resource()
    
    [ Upstream commit 20f1932e2282c58cb5ac59517585206cf5b385ae ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 662bfdea9200dddad5ab0d2042265cfe42a3baa1
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Jun 7 22:36:02 2021 +0800

    net: mvpp2: check return value after calling platform_get_resource()
    
    [ Upstream commit 0bb51a3a385790a4be20085494cf78f70dadf646 ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09846c2990d91736566395e6b01674b2258cd702
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Jun 7 21:38:37 2021 +0800

    net: bcmgenet: check return value after calling platform_get_resource()
    
    [ Upstream commit 74325bf0104573c6dfce42837139aeef3f34be76 ]
    
    It will cause null-ptr-deref if platform_get_resource() returns NULL,
    we need check the return value.
    
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 34218ccb387c1e5e94b2baa6e337fb0367edede0
Author: Xianting Tian <xianting.tian@linux.alibaba.com>
Date:   Sat Jun 5 11:31:00 2021 -0400

    virtio_net: Remove BUG() to avoid machine dead
    
    [ Upstream commit 85eb1389458d134bdb75dad502cc026c3753a619 ]
    
    We should not directly BUG() when there is hdr error, it is
    better to output a print when such error happens. Currently,
    the caller of xmit_skb() already did it.
    
    Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c9a064cf60d759df96f009ab97a0cfea31e31d70
Author: Liwei Song <liwei.song@windriver.com>
Date:   Mon Apr 19 17:31:06 2021 +0800

    ice: set the value of global config lock timeout longer
    
    [ Upstream commit fb3612840d4f587a0af9511a11d7989d1fa48206 ]
    
    It may need hold Global Config Lock a longer time when download DDP
    package file, extend the timeout value to 5000ms to ensure that
    download can be finished before other AQ command got time to run,
    this will fix the issue below when probe the device, 5000ms is a test
    value that work with both Backplane and BreakoutCable NVM image:
    
    ice 0000:f4:00.0: VSI 12 failed lan queue config, error ICE_ERR_CFG
    ice 0000:f4:00.0: Failed to delete VSI 12 in FW - error: ICE_ERR_AQ_TIMEOUT
    ice 0000:f4:00.0: probe failed due to setup PF switch: -12
    ice: probe of 0000:f4:00.0 failed with error -12
    
    Signed-off-by: Liwei Song <liwei.song@windriver.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f738b0028b5cc3c42ca63da0547b6ec612bc0c5
Author: Radim Pavlik <radim.pavlik@tbs-biometrics.com>
Date:   Tue Jun 1 10:48:18 2021 +0000

    pinctrl: mcp23s08: fix race condition in irq handler
    
    [ Upstream commit 897120d41e7afd9da435cb00041a142aeeb53c07 ]
    
    Checking value of MCP_INTF in mcp23s08_irq suggests that the handler may be
    called even when there is no interrupt pending.
    
    But the actual interrupt could happened between reading MCP_INTF and MCP_GPIO.
    In this situation we got nothing from MCP_INTF, but the event gets acknowledged
    on the expander by reading MCP_GPIO. This leads to losing events.
    
    Fix the problem by not reading any register until we see something in MCP_INTF.
    
    The error was reproduced and fix tested on MCP23017.
    
    Signed-off-by: Radim Pavlik <radim.pavlik@tbs-biometrics.com>
    Link: https://lore.kernel.org/r/AM7PR06MB6769E1183F68DEBB252F665ABA3E9@AM7PR06MB6769.eurprd06.prod.outlook.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e20d40538987b78cdaadcfa2a88344bf97608eb1
Author: Joe Thornber <ejt@redhat.com>
Date:   Tue Apr 13 09:03:49 2021 +0100

    dm space maps: don't reset space map allocation cursor when committing
    
    [ Upstream commit 5faafc77f7de69147d1e818026b9a0cbf036a7b2 ]
    
    Current commit code resets the place where the search for free blocks
    will begin back to the start of the metadata device.  There are a couple
    of repercussions to this:
    
    - The first allocation after the commit is likely to take longer than
      normal as it searches for a free block in an area that is likely to
      have very few free blocks (if any).
    
    - Any free blocks it finds will have been recently freed.  Reusing them
      means we have fewer old copies of the metadata to aid recovery from
      hardware error.
    
    Fix these issues by leaving the cursor alone, only resetting when the
    search hits the end of the metadata device.
    
    Signed-off-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 54e433742cae8668b43d361f1bd48ec234b4e3a6
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Tue Jun 1 19:07:49 2021 +0800

    RDMA/cxgb4: Fix missing error code in create_qp()
    
    [ Upstream commit aeb27bb76ad8197eb47890b1ff470d5faf8ec9a5 ]
    
    The error code is missing in this code scenario so 0 will be returned. Add
    the error code '-EINVAL' to the return value 'ret'.
    
    Eliminates the follow smatch warning:
    
    drivers/infiniband/hw/cxgb4/qp.c:298 create_qp() warn: missing error code 'ret'.
    
    Link: https://lore.kernel.org/r/1622545669-20625-1-git-send-email-jiapeng.chong@linux.alibaba.com
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f0be58ec9931907e980cf21737e51d369808eb95
Author: Willy Tarreau <w@1wt.eu>
Date:   Sat May 29 13:07:46 2021 +0200

    ipv6: use prandom_u32() for ID generation
    
    [ Upstream commit 62f20e068ccc50d6ab66fdb72ba90da2b9418c99 ]
    
    This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
    table for IP ID generation"), but focusing on some specific aspects
    of IPv6.
    
    Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
    minimum MTU of 1280, it's much less easy to force a remote peer to
    produce many fragments to explore its ID sequence. In addition packet
    IDs are 32-bit in IPv6, which further complicates their analysis. On
    the other hand, it is often easier to choose among plenty of possible
    source addresses and partially work around the bigger hash table the
    commit above permits, which leaves IPv6 partially exposed to some
    possibilities of remote analysis at the risk of weakening some
    protocols like DNS if some IDs can be predicted with a good enough
    probability.
    
    Given the wide range of permitted IDs, the risk of collision is extremely
    low so there's no need to rely on the positive increment algorithm that
    is shared with the IPv4 code via ip_idents_reserve(). We have a fast
    PRNG, so let's simply call prandom_u32() and be done with it.
    
    Performance measurements at 10 Gbps couldn't show any difference with
    the previous code, even when using a single core, because due to the
    large fragments, we're limited to only ~930 kpps at 10 Gbps and the cost
    of the random generation is completely offset by other operations and by
    the network transfer time. In addition, this change removes the need to
    update a shared entry in the idents table so it may even end up being
    slightly faster on large scale systems where this matters.
    
    The risk of at least one collision here is about 1/80 million among
    10 IDs, 1/850k among 100 IDs, and still only 1/8.5k among 1000 IDs,
    which remains very low compared to IPv4 where all IDs are reused
    every 4 to 80ms on a 10 Gbps flow depending on packet sizes.
    
    Reported-by: Amit Klein <aksecurity@gmail.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20210529110746.6796-1-w@1wt.eu
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d80baef871d1678acef4779444c5aec1fc035e44
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun May 16 19:30:35 2021 +0300

    clk: tegra: Ensure that PLLU configuration is applied properly
    
    [ Upstream commit a7196048cd5168096c2c4f44a3939d7a6dcd06b9 ]
    
    The PLLU (USB) consists of the PLL configuration itself and configuration
    of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114,
    where T114 immediately bails out if PLLU is enabled and T30 re-enables
    a potentially already enabled PLL (left after bootloader) and then fully
    reprograms it, which could be unsafe to do. The correct way should be to
    skip enabling of the PLL if it's already enabled and then apply
    configuration to the outputs. This patch doesn't fix any known problems,
    it's a minor improvement.
    
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a5ef472a70978ad51c29871515d6185de397acae
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu May 27 13:36:38 2021 +0900

    clk: renesas: r8a77995: Add ZA2 clock
    
    [ Upstream commit 790c06cc5df263cdaff748670cc65958c81b0951 ]
    
    R-Car D3 ZA2 clock is from PLL0D3 or S0,
    and it can be controlled by ZA2CKCR.
    It is needed for R-Car Sound, but is not used so far.
    Using default settings is very enough at this point.
    This patch adds it by DEF_FIXED().
    
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/87pmxclrmy.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 395c2fd5e5b496139130104667e81a558e5ada74
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date:   Thu Mar 25 17:38:24 2021 -0700

    e100: handle eeprom as little endian
    
    [ Upstream commit d4ef55288aa2e1b76033717242728ac98ddc4721 ]
    
    Sparse tool was warning on some implicit conversions from
    little endian data read from the EEPROM on the e100 cards.
    
    Fix these by being explicit about the conversions using
    le16_to_cpu().
    
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3638705ecd5ad2785e996f820121c0ad15ce64b5
Author: Arturo Giusti <koredump@protonmail.com>
Date:   Tue May 18 12:34:57 2021 +0200

    udf: Fix NULL pointer dereference in udf_symlink function
    
    [ Upstream commit fa236c2b2d4436d9f19ee4e5d5924e90ffd7bb43 ]
    
    In function udf_symlink, epos.bh is assigned with the value returned
    by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
    and returns the value of sb_getblk function that could be NULL.
    Then, epos.bh is used without any check, causing a possible
    NULL pointer dereference when sb_getblk fails.
    
    This fix adds a check to validate the value of epos.bh.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=213083
    Signed-off-by: Arturo Giusti <koredump@protonmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2fda4ff855d8be14338cc383fad3f2fa2f7d30aa
Author: Xie Yongji <xieyongji@bytedance.com>
Date:   Mon May 17 16:49:12 2021 +0800

    drm/virtio: Fix double free on probe failure
    
    [ Upstream commit cec7f1774605a5ef47c134af62afe7c75c30b0ee ]
    
    The virtio_gpu_init() will free vgdev and vgdev->vbufs on failure.
    But such failure will be caught by virtio_gpu_probe() and then
    virtio_gpu_release() will be called to do some cleanup which
    will free vgdev and vgdev->vbufs again. So let's set dev->dev_private
    to NULL to avoid double free.
    
    Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20210517084913.403-2-xieyongji@bytedance.com
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 47b4b8f0d3780959a15e0118da83c42c688d14e6
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Mon May 17 15:15:45 2021 +0300

    reiserfs: add check for invalid 1st journal block
    
    [ Upstream commit a149127be52fa7eaf5b3681a0317a2bbb772d5a9 ]
    
    syzbot reported divide error in reiserfs.
    The problem was in incorrect journal 1st block.
    
    Syzbot's reproducer manualy generated wrong superblock
    with incorrect 1st block. In journal_init() wasn't
    any checks about this particular case.
    
    For example, if 1st journal block is before superblock
    1st block, it can cause zeroing important superblock members
    in do_journal_end().
    
    Link: https://lore.kernel.org/r/20210517121545.29645-1-paskripkin@gmail.com
    Reported-by: syzbot+0ba9909df31c6a36974d@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e626b6f873f2cce6d4c5ed555df64f0c9fc3a3db
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Wed May 12 23:43:24 2021 +0200

    net: Treat __napi_schedule_irqoff() as __napi_schedule() on PREEMPT_RT
    
    [ Upstream commit 8380c81d5c4fced6f4397795a5ae65758272bbfd ]
    
    __napi_schedule_irqoff() is an optimized version of __napi_schedule()
    which can be used where it is known that interrupts are disabled,
    e.g. in interrupt-handlers, spin_lock_irq() sections or hrtimer
    callbacks.
    
    On PREEMPT_RT enabled kernels this assumptions is not true. Force-
    threaded interrupt handlers and spinlocks are not disabling interrupts
    and the NAPI hrtimer callback is forced into softirq context which runs
    with interrupts enabled as well.
    
    Chasing all usage sites of __napi_schedule_irqoff() is a whack-a-mole
    game so make __napi_schedule_irqoff() invoke __napi_schedule() for
    PREEMPT_RT kernels.
    
    The callers of ____napi_schedule() in the networking core have been
    audited and are correct on PREEMPT_RT kernels as well.
    
    Reported-by: Juri Lelli <juri.lelli@redhat.com>
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Juri Lelli <juri.lelli@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a7a7b2848312cc4c3a42b6e42a8ab2e441857aba
Author: Zou Wei <zou_wei@huawei.com>
Date:   Wed May 12 15:00:24 2021 +0800

    atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
    
    [ Upstream commit 34e7434ba4e97f4b85c1423a59b2922ba7dff2ea ]
    
    This module's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f2818185da0fe82a932f0856633038b66faf124
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue May 11 14:58:53 2021 +0800

    mISDN: fix possible use-after-free in HFC_cleanup()
    
    [ Upstream commit 009fc857c5f6fda81f2f7dd851b2d54193a8e733 ]
    
    This module's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 89ce0b0747f319eb70f85bc820dcc43cebbd5417
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue May 11 14:53:36 2021 +0800

    atm: iphase: fix possible use-after-free in ia_module_exit()
    
    [ Upstream commit 1c72e6ab66b9598cac741ed397438a52065a8f1f ]
    
    This module's remove path calls del_timer(). However, that function
    does not wait until the timer handler finishes. This means that the
    timer handler may still be running after the driver's remove function
    has finished, which would result in a use-after-free.
    
    Fix by calling del_timer_sync(), which makes sure the timer handler
    has finished, and unable to re-schedule itself.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 909bfdecf39843d1e42a9480a9c3ed49f7579707
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Mon Jun 29 21:15:32 2020 +0800

    hugetlb: clear huge pte during flush function on mips platform
    
    [ Upstream commit 33ae8f801ad8bec48e886d368739feb2816478f2 ]
    
    If multiple threads are accessing the same huge page at the same
    time, hugetlb_cow will be called if one thread write the COW huge
    page. And function huge_ptep_clear_flush is called to notify other
    threads to clear the huge pte tlb entry. The other threads clear
    the huge pte tlb entry and reload it from page table, the reload
    huge pte entry may be old.
    
    This patch fixes this issue on mips platform, and it clears huge
    pte entry before notifying other threads to flush current huge
    page entry, it is similar with other architectures.
    
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 15f4e53d2e6ace8eb0a64dea56907164cdb245e4
Author: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Date:   Mon Apr 19 17:50:53 2021 -0400

    drm/amd/display: fix use_max_lb flag for 420 pixel formats
    
    [ Upstream commit 8809a7a4afe90ad9ffb42f72154d27e7c47551ae ]
    
    Right now the flag simply selects memory config 0 when flag is true
    however 420 modes benefit more from memory config 3.
    
    Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
    Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
    Acked-by: Stylon Wang <stylon.wang@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06805760433f4787d7975d8817f657265c9fe567
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon May 10 19:39:30 2021 +0300

    net: pch_gbe: Use proper accessors to BE data in pch_ptp_match()
    
    [ Upstream commit 443ef39b499cc9c6635f83238101f1bb923e9326 ]
    
    Sparse is not happy about handling of strict types in pch_ptp_match():
    
      .../pch_gbe_main.c:158:33: warning: incorrect type in argument 2 (different base types)
      .../pch_gbe_main.c:158:33:    expected unsigned short [usertype] uid_hi
      .../pch_gbe_main.c:158:33:    got restricted __be16 [usertype]
      .../pch_gbe_main.c:158:45: warning: incorrect type in argument 3 (different base types)
      .../pch_gbe_main.c:158:45:    expected unsigned int [usertype] uid_lo
      .../pch_gbe_main.c:158:45:    got restricted __be32 [usertype]
      .../pch_gbe_main.c:158:56: warning: incorrect type in argument 4 (different base types)
      .../pch_gbe_main.c:158:56:    expected unsigned short [usertype] seqid
      .../pch_gbe_main.c:158:56:    got restricted __be16 [usertype]
    
    Fix that by switching to use proper accessors to BE data.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Tested-by: Flavio Suligoi <f.suligoi@asem.it>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 38fe84738c50b248414de3c9163a217f7270cf20
Author: Jack Zhang <Jack.Zhang1@amd.com>
Date:   Tue Apr 27 17:08:47 2021 +0800

    drm/amd/amdgpu/sriov disable all ip hw status by default
    
    [ Upstream commit 95ea3dbc4e9548d35ab6fbf67675cef8c293e2f5 ]
    
    Disable all ip's hw status to false before any hw_init.
    Only set it to true until its hw_init is executed.
    
    The old 5.9 branch has this change but somehow the 5.11 kernrel does
    not have this fix.
    
    Without this change, sriov tdr have gfx IB test fail.
    
    Signed-off-by: Jack Zhang <Jack.Zhang1@amd.com>
    Review-by: Emily Deng <Emily.Deng@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c7a586e6634f1118032a249ec03740ba9fe1fa6
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Thu Apr 15 13:00:39 2021 +0200

    drm/zte: Don't select DRM_KMS_FB_HELPER
    
    [ Upstream commit a50e74bec1d17e95275909660c6b43ffe11ebcf0 ]
    
    Selecting DRM_FBDEV_EMULATION will include the correct settings for
    fbdev emulation. Drivers should not override this.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-4-tzimmermann@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2c3a3c3714efc6dfad686b9549f033bf52576835
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Thu Apr 15 13:00:38 2021 +0200

    drm/mxsfb: Don't select DRM_KMS_FB_HELPER
    
    [ Upstream commit 13b29cc3a722c2c0bc9ab9f72f9047d55d08a2f9 ]
    
    Selecting DRM_FBDEV_EMULATION will include the correct settings for
    fbdev emulation. Drivers should not override this.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Acked-by: Stefan Agner <stefan@agner.ch>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210415110040.23525-3-tzimmermann@suse.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eaa21859bd74124ec87e813dd81c9df81c8a20cd
Author: Johan Hovold <johan@kernel.org>
Date:   Fri May 21 15:30:26 2021 +0200

    mmc: vub3000: fix control-request direction
    
    commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the SET_ROM_WAIT_STATES request which erroneously used
    usb_rcvctrlpipe().
    
    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Cc: stable@vger.kernel.org      # 3.0
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1f9f514b764f70e79debbfda61d198bdc8e7f09
Author: Bean Huo <beanhuo@micron.com>
Date:   Tue May 4 22:32:09 2021 +0200

    mmc: block: Disable CMDQ on the ioctl path
    
    commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream.
    
    According to the eMMC Spec:
    "When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN
    field is set to ‘1’) class 11 commands are the only method through
    which data transfer tasks can be issued. Existing data transfer
    commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when
    command queuing is enabled."
    which means if CMDQ is enabled, the FFU commands will not be supported.
    To fix this issue, just simply disable CMDQ on the ioctl path, and
    re-enable CMDQ once ioctl request is completed.
    
    Tested-by: Michael Brunner <Michael.Brunner@kontron.com>
    Signed-off-by: Bean Huo <beanhuo@micron.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Fixes: 1e8e55b67030 (mmc: block: Add CQE support)
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3bed778ac53a494415eb98263b969b941aacb96
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Jul 1 14:20:58 2021 -0300

    perf llvm: Return -ENOMEM when asprintf() fails
    
    [ Upstream commit c435c166dcf526ac827bc964d82cc0d5e7a1fd0b ]
    
    Zhihao sent a patch but it made llvm__compile_bpf() return what
    asprintf() returns on error, which is just -1, but since this function
    returns -errno, fix it by returning -ENOMEM for this case instead.
    
    Fixes: cb76371441d098 ("perf llvm: Allow passing options to llc ...")
    Fixes: 5eab5a7ee032ac ("perf llvm: Display eBPF compiling command ...")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Reported-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Andrii Nakryiko <andrii@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Yu Kuai <yukuai3@huawei.com>
    Cc: clang-built-linux@googlegroups.com
    Link: http://lore.kernel.org/lkml/20210609115945.2193194-1-chengzhihao1@huawei.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8ceeafb911cc056bb8d4b804b04b54a214a0a684
Author: Dave Hansen <dave.hansen@linux.intel.com>
Date:   Wed Jun 30 18:56:53 2021 -0700

    selftests/vm/pkeys: fix alloc_random_pkey() to make it really, really random
    
    [ Upstream commit f36ef407628835a7d7fb3d235b1f1aac7022d9a3 ]
    
    Patch series "selftests/vm/pkeys: Bug fixes and a new test".
    
    There has been a lot of activity on the x86 front around the XSAVE
    architecture which is used to context-switch processor state (among other
    things).  In addition, AMD has recently joined the protection keys club by
    adding processor support for PKU.
    
    The AMD implementation helped uncover a kernel bug around the PKRU "init
    state", which actually applied to Intel's implementation but was just
    harder to hit.  This series adds a test which is expected to help find
    this class of bug both on AMD and Intel.  All the work around pkeys on x86
    also uncovered a few bugs in the selftest.
    
    This patch (of 4):
    
    The "random" pkey allocation code currently does the good old:
    
            srand((unsigned int)time(NULL));
    
    *But*, it unfortunately does this on every random pkey allocation.
    
    There may be thousands of these a second.  time() has a one second
    resolution.  So, each time alloc_random_pkey() is called, the PRNG is
    *RESET* to time().  This is nasty.  Normally, if you do:
    
            srand(<ANYTHING>);
            foo = rand();
            bar = rand();
    
    You'll be quite guaranteed that 'foo' and 'bar' are different.  But, if
    you do:
    
            srand(1);
            foo = rand();
            srand(1);
            bar = rand();
    
    You are quite guaranteed that 'foo' and 'bar' are the *SAME*.  The recent
    "fix" effectively forced the test case to use the same "random" pkey for
    the whole test, unless the test run crossed a second boundary.
    
    Only run srand() once at program startup.
    
    This explains some very odd and persistent test failures I've been seeing.
    
    Link: https://lkml.kernel.org/r/20210611164153.91B76FB8@viggo.jf.intel.com
    Link: https://lkml.kernel.org/r/20210611164155.192D00FF@viggo.jf.intel.com
    Fixes: 6e373263ce07 ("selftests/vm/pkeys: fix alloc_random_pkey() to make it really random")
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Cc: Ram Pai <linuxram@us.ibm.com>
    Cc: Sandipan Das <sandipan@linux.ibm.com>
    Cc: Florian Weimer <fweimer@redhat.com>
    Cc: "Desnes A. Nunes do Rosario" <desnesn@linux.vnet.ibm.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Michal Suchanek <msuchanek@suse.de>
    Cc: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c4e4a6f1c976aba407fa45fd95e4564291324eb9
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Wed Jun 30 18:47:57 2021 -0700

    mm/huge_memory.c: don't discard hugepage if other processes are mapping it
    
    [ Upstream commit babbbdd08af98a59089334eb3effbed5a7a0cf7f ]
    
    If other processes are mapping any other subpages of the hugepage, i.e.
    in pte-mapped thp case, page_mapcount() will return 1 incorrectly.  Then
    we would discard the page while other processes are still mapping it.  Fix
    it by using total_mapcount() which can tell whether other processes are
    still mapping it.
    
    Link: https://lkml.kernel.org/r/20210511134857.1581273-6-linmiaohe@huawei.com
    Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
    Reviewed-by: Yang Shi <shy828301@gmail.com>
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
    Cc: Anshuman Khandual <anshuman.khandual@arm.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Ralph Campbell <rcampbell@nvidia.com>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: William Kucharski <william.kucharski@oracle.com>
    Cc: Zi Yan <ziy@nvidia.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d067a6b62b430f7bedef9d4a2f600b7edf58e417
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Jun 28 14:08:12 2021 -0600

    vfio/pci: Handle concurrent vma faults
    
    [ Upstream commit 6a45ece4c9af473555f01f0f8b97eba56e3c7d0d ]
    
    io_remap_pfn_range() will trigger a BUG_ON if it encounters a
    populated pte within the mapping range.  This can occur because we map
    the entire vma on fault and multiple faults can be blocked behind the
    vma_lock.  This leads to traces like the one reported below.
    
    We can use our vma_list to test whether a given vma is mapped to avoid
    this issue.
    
    [ 1591.733256] kernel BUG at mm/memory.c:2177!
    [ 1591.739515] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [ 1591.747381] Modules linked in: vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
    [ 1591.760536] CPU: 2 PID: 227 Comm: lcore-worker-2 Tainted: G O 5.11.0-rc3+ #1
    [ 1591.770735] Hardware name:  , BIOS HixxxxFPGA 1P B600 V121-1
    [ 1591.778872] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
    [ 1591.786134] pc : remap_pfn_range+0x214/0x340
    [ 1591.793564] lr : remap_pfn_range+0x1b8/0x340
    [ 1591.799117] sp : ffff80001068bbd0
    [ 1591.803476] x29: ffff80001068bbd0 x28: 0000042eff6f0000
    [ 1591.810404] x27: 0000001100910000 x26: 0000001300910000
    [ 1591.817457] x25: 0068000000000fd3 x24: ffffa92f1338e358
    [ 1591.825144] x23: 0000001140000000 x22: 0000000000000041
    [ 1591.832506] x21: 0000001300910000 x20: ffffa92f141a4000
    [ 1591.839520] x19: 0000001100a00000 x18: 0000000000000000
    [ 1591.846108] x17: 0000000000000000 x16: ffffa92f11844540
    [ 1591.853570] x15: 0000000000000000 x14: 0000000000000000
    [ 1591.860768] x13: fffffc0000000000 x12: 0000000000000880
    [ 1591.868053] x11: ffff0821bf3d01d0 x10: ffff5ef2abd89000
    [ 1591.875932] x9 : ffffa92f12ab0064 x8 : ffffa92f136471c0
    [ 1591.883208] x7 : 0000001140910000 x6 : 0000000200000000
    [ 1591.890177] x5 : 0000000000000001 x4 : 0000000000000001
    [ 1591.896656] x3 : 0000000000000000 x2 : 0168044000000fd3
    [ 1591.903215] x1 : ffff082126261880 x0 : fffffc2084989868
    [ 1591.910234] Call trace:
    [ 1591.914837]  remap_pfn_range+0x214/0x340
    [ 1591.921765]  vfio_pci_mmap_fault+0xac/0x130 [vfio_pci]
    [ 1591.931200]  __do_fault+0x44/0x12c
    [ 1591.937031]  handle_mm_fault+0xcc8/0x1230
    [ 1591.942475]  do_page_fault+0x16c/0x484
    [ 1591.948635]  do_translation_fault+0xbc/0xd8
    [ 1591.954171]  do_mem_abort+0x4c/0xc0
    [ 1591.960316]  el0_da+0x40/0x80
    [ 1591.965585]  el0_sync_handler+0x168/0x1b0
    [ 1591.971608]  el0_sync+0x174/0x180
    [ 1591.978312] Code: eb1b027f 540000c0 f9400022 b4fffe02 (d4210000)
    
    Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking")
    Reported-by: Zeng Tao <prime.zeng@hisilicon.com>
    Suggested-by: Zeng Tao <prime.zeng@hisilicon.com>
    Link: https://lore.kernel.org/r/162497742783.3883260.3282953006487785034.stgit@omen
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0dc3e70a576d93da91f46d8fc6f23cbc5fa41e59
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Jun 25 00:49:04 2021 +0200

    arm64: dts: marvell: armada-37xx: Fix reg for standard variant of UART
    
    [ Upstream commit 2cbfdedef39fb5994b8f1e1df068eb8440165975 ]
    
    UART1 (standard variant with DT node name 'uart0') has register space
    0x12000-0x12018 and not whole size 0x200. So fix also this in example.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: c737abc193d1 ("arm64: dts: marvell: Fix A37xx UART0 register size")
    Link: https://lore.kernel.org/r/20210624224909.6350-6-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0e3b7b2e7843ca31c512fa458f72bc7839dea7d1
Author: Pali Rohár <pali@kernel.org>
Date:   Fri Jun 25 00:49:02 2021 +0200

    serial: mvebu-uart: correctly calculate minimal possible baudrate
    
    [ Upstream commit deeaf963569a0d9d1b08babb771f61bb501a5704 ]
    
    For default (x16) scheme which is currently used by mvebu-uart.c driver,
    maximal divisor of UART base clock is 1023*16. Therefore there is limit for
    minimal supported baudrate. This change calculate it correctly and prevents
    setting invalid divisor 0 into hardware registers.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
    Link: https://lore.kernel.org/r/20210624224909.6350-4-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3d1e4f17838c3e5d2b541a4bdb8e623773c96367
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Wed Jun 23 14:12:45 2021 +1000

    powerpc: Offline CPU in stop_this_cpu()
    
    [ Upstream commit bab26238bbd44d5a4687c0a64fd2c7f2755ea937 ]
    
    printk_safe_flush_on_panic() has special lock breaking code for the case
    where we panic()ed with the console lock held. It relies on panic IPI
    causing other CPUs to mark themselves offline.
    
    Do as most other architectures do.
    
    This effectively reverts commit de6e5d38417e ("powerpc: smp_send_stop do
    not offline stopped CPUs"), unfortunately it may result in some false
    positive warnings, but the alternative is more situations where we can
    crash without getting messages out.
    
    Fixes: de6e5d38417e ("powerpc: smp_send_stop do not offline stopped CPUs")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210623041245.865134-1-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 09f064fcadc7dad2ffc69232d58c8a29b2e5e430
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Fri May 21 13:21:01 2021 +0200

    leds: ktd2692: Fix an error handling path
    
    [ Upstream commit ee78b9360e14c276f5ceaa4a0d06f790f04ccdad ]
    
    In 'ktd2692_parse_dt()', if an error occurs after a successful
    'regulator_enable()' call, we should call 'regulator_enable()'.
    
    This is the same in 'ktd2692_probe()', if an error occurs after a
    successful 'ktd2692_parse_dt()' call.
    
    Instead of adding 'regulator_enable()' in several places, implement a
    resource managed solution and simplify the remove function accordingly.
    
    Fixes: b7da8c5c725c ("leds: Add ktd2692 flash LED driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21da01972675769d2908652e7785f5ce20254a7a
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 11:06:46 2021 +0800

    leds: as3645a: Fix error return code in as3645a_parse_node()
    
    [ Upstream commit 96a30960a2c5246c8ffebe8a3c9031f9df094d97 ]
    
    Return error code -ENODEV rather than '0' when the indicator node can not
    be found.
    
    Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 01b00e46253151d58a7db8ca3e1502ec1945a8d0
Author: Chung-Chiang Cheng <shepjeng@gmail.com>
Date:   Fri Jun 18 15:59:25 2021 +0800

    configfs: fix memleak in configfs_release_bin_file
    
    [ Upstream commit 3c252b087de08d3cb32468b54a158bd7ad0ae2f7 ]
    
    When reading binary attributes in progress, buffer->bin_buffer is setup in
    configfs_read_bin_file() but never freed.
    
    Fixes: 03607ace807b4 ("configfs: implement binary attributes")
    Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>
    [hch: move the vfree rather than duplicating it]
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e462d5387ef2f542d8d2e7a55c169f98d28fd302
Author: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Date:   Fri Jun 18 18:07:41 2021 +0300

    ASoC: atmel-i2s: Fix usage of capture and playback at the same time
    
    [ Upstream commit 3b7961a326f8a7e03f54a19f02fedae8d488b80f ]
    
    For both capture and playback streams to work at the same time, only the
    needed values from a register need to be updated. Also, clocks should be
    enabled only when the first stream is started and stopped when there is no
    running stream.
    
    Fixes: b543e467d1a9 ("ASoC: atmel-i2s: add driver for the new Atmel I2S controller")
    Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
    Link: https://lore.kernel.org/r/20210618150741.401739-2-codrin.ciubotariu@microchip.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3df5960043203c68d8d1ca08c23c49903140f442
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Apr 23 22:46:24 2021 +0200

    extcon: max8997: Add missing modalias string
    
    [ Upstream commit dc11fc2991e9efbceef93912b83e333d2835fb19 ]
    
    The platform device driver name is "max8997-muic", so advertise it
    properly in the modalias string. This fixes automated module loading when
    this driver is compiled as a module.
    
    Fixes: b76668ba8a77 ("Extcon: add MAX8997 extcon driver")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 06a65c0d8aaf2c010d6dab7f8358e4d6692dcc35
Author: Stephan Gerhold <stephan@gerhold.net>
Date:   Mon May 31 15:34:35 2021 +0200

    extcon: sm5502: Drop invalid register write in sm5502_reg_data
    
    [ Upstream commit d25b224f8e5507879b36a769a6d1324cf163466c ]
    
    When sm5502_init_dev_type() iterates over sm5502_reg_data to
    initialize the registers it is limited by ARRAY_SIZE(sm5502_reg_data).
    There is no need to add another empty element to sm5502_reg_data.
    
    Having the additional empty element in sm5502_reg_data will just
    result in writing 0xff to register 0x00, which does not really
    make sense.
    
    Fixes: 914b881f9452 ("extcon: sm5502: Add support new SM5502 extcon device driver")
    Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d731d20c066c9ef334bfa617fe64031bb2acf3ce
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jun 5 15:17:43 2021 +0200

    phy: ti: dm816x: Fix the error handling path in 'dm816x_usb_phy_probe()
    
    [ Upstream commit f7eedcb8539ddcbb6fe7791f1b4ccf43f905c72f ]
    
    Add an error handling path in the probe to release some resources, as
    already done in the remove function.
    
    Fixes: 609adde838f4 ("phy: Add a driver for dm816x USB PHY")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/ac5136881f6bdec50be19b3bf73b3bc1b15ef1f1.1622898974.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a2ec9ab0b241e82aeedf353a678ad8655a4c271a
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Fri May 14 16:13:00 2021 +0800

    scsi: mpt3sas: Fix error return value in _scsih_expander_add()
    
    [ Upstream commit d6c2ce435ffe23ef7f395ae76ec747414589db46 ]
    
    When an expander does not contain any 'phys', an appropriate error code -1
    should be returned, as done elsewhere in this function. However, we
    currently do not explicitly assign this error code to 'rc'. As a result, 0
    was incorrectly returned.
    
    Link: https://lore.kernel.org/r/20210514081300.6650-1-thunder.leizhen@huawei.com
    Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a4498d0a460b80f797841ad39ec1506aeaedfae
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Jun 1 20:58:14 2021 +0800

    mtd: rawnand: marvell: add missing clk_disable_unprepare() on error in marvell_nfc_resume()
    
    [ Upstream commit ae94c49527aa9bd3b563349adc4b5617747ca6bd ]
    
    Add clk_disable_unprepare() on error path in marvell_nfc_resume().
    
    Fixes: bd9c3f9b3c00 ("mtd: rawnand: marvell: add suspend and resume hooks")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20210601125814.3260364-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 193dc4417956ce56413ff1d57b5f26541eedba34
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jun 16 11:27:44 2021 +0200

    of: Fix truncation of memory sizes on 32-bit platforms
    
    [ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ]
    
    Variable "size" has type "phys_addr_t", which can be either 32-bit or
    64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
    32-bit systems.  Hence the cast in
    
        (unsigned long)size / SZ_1M
    
    may truncate a 64-bit size to 32-bit, as casts have a higher operator
    precedence than divisions.
    
    Fix this by inverting the order of the cast and division, which should
    be safe for memory blocks smaller than 4 PiB.  Note that the division is
    actually a shift, as SZ_1M is a power-of-two constant, hence there is no
    need to use div_u64().
    
    While at it, use "%lu" to format "unsigned long".
    
    Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory")
    Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9a305239bd781ae29cb17be747619a5c521b0c7f
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Wed Jun 16 14:56:04 2021 +0100

    ASoC: cs42l42: Correct definition of CS42L42_ADC_PDN_MASK
    
    [ Upstream commit fac165f22ac947b55407cd3a60a2a9824f905235 ]
    
    The definition of CS42L42_ADC_PDN_MASK was incorrectly defined
    as the HP_PDN bit.
    
    Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec")
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210616135604.19363-1-rf@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7cd3fd394f6581e992c5879bd4bddc18a3d543fb
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jun 13 16:23:01 2021 +0100

    iio: prox: isl29501: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 92babc9938ebbf4050f2fba774836f7edc16a570 ]
    
    Add __aligned(8) to ensure the buffer passed to
    iio_push_to_buffers_with_timestamp() is suitable for the naturally
    aligned timestamp that will be inserted.
    
    Here an explicit structure is not used, because the holes would
    necessitate the addition of an explict memset(), to avoid a kernel
    data leak, making for a less minimal fix.
    
    Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Mathieu Othacehe <m.othacehe@gmail.com>
    Reviewed-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210613152301.571002-9-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 494c06f1c7ab6d52382b0a77c8c29abb9b7cb08a
Author: Maciej W. Rozycki <macro@orcam.me.uk>
Date:   Thu Jun 10 20:38:34 2021 +0200

    serial: 8250: Actually allow UPF_MAGIC_MULTIPLIER baud rates
    
    [ Upstream commit 78bcae8616ac277d6cb7f38e211493948ed73e30 ]
    
    Support for magic baud rate divisors of 32770 and 32769 used with SMSC
    Super I/O chips for extra baud rates of 230400 and 460800 respectively
    where base rate is 115200[1] has been added around Linux 2.5.64, which
    predates our repo history, but the origin could be identified as commit
    2a717aad772f ("Merge with Linux 2.5.64.") with the old MIPS/Linux repo
    also at: <git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git>.
    
    Code that is now in `serial8250_do_get_divisor' was added back then to
    `serial8250_get_divisor', but that code would only ever trigger if one
    of the higher baud rates was actually requested, and that cannot ever
    happen, because the earlier call to `serial8250_get_baud_rate' never
    returns them.  This is because it calls `uart_get_baud_rate' with the
    maximum requested being the base rate, that is clk/16 or 115200 for SMSC
    chips at their nominal clock rate.
    
    Fix it then and allow UPF_MAGIC_MULTIPLIER baud rates to be selected, by
    requesting the maximum baud rate of clk/4 rather than clk/16 if the flag
    has been set.  Also correct the minimum baud rate, observing that these
    ports only support actual (non-magic) divisors of up to 32767 only.
    
    References:
    
    [1] "FDC37M81x, PC98/99 Compliant Enhanced Super I/O Controller with
        Keyboard/Mouse Wake-Up", Standard Microsystems Corporation, Rev.
        03/27/2000, Table 31 - "Baud Rates", p. 77
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
    Link: https://lore.kernel.org/r/alpine.DEB.2.21.2105190412280.29169@angie.orcam.me.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3f1d21f2dc7774bebba14d985e39cc913480f150
Author: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Date:   Mon Jun 14 12:06:17 2021 +0200

    staging: mt7621-dts: fix pci address for PCI memory range
    
    [ Upstream commit 5b4f167ef3555ec4c334a8dc89c1b44bb2c6bff5 ]
    
    Driver code call 'devm_of_pci_get_host_bridge_resources'
    to get resources and properly fill 'bridge->windows' and
    'bridge->dma_ranges'. After parsing the ranges and store
    as resources, at the end it makes a call to pci function
    'pci_add_resource_offset' to set the offset for the
    memory resource. To calculate offset, resource start address
    subtracts pci address of the range. MT7621 does not need
    any offset for the memory resource. Moreover, setting an
    offset got into 'WARN_ON' calls from pci devices driver code.
    Until now memory range pci_addr was being '0x00000000' and
    res->start is '0x60000000' but becase pci controller driver
    was manually setting resources and adding them using pci function
    'pci_add_resource' where a zero is passed as offset, things
    was properly working. Since PCI_IOBASE is defined now for
    ralink we don't set nothing manually anymore so we have to
    properly fix PCI address for this range to make things work
    and the new pci address must be set to '0x60000000'. Doing
    in this way the subtract result obtain zero as offset
    and pci device driver code properly works.
    
    Fixes: d59578da2bb8 ("staging: mt7621-dts: add dts files")
    Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
    Link: https://lore.kernel.org/r/20210614100617.28753-4-sergio.paracuellos@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 58f26f9463b86903018483205d5367016faac6bd
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 14 12:58:36 2021 +0300

    staging: gdm724x: check for overflow in gdm_lte_netif_rx()
    
    [ Upstream commit 7002b526f4ff1f6da34356e67085caafa6be383a ]
    
    This code assumes that "len" is at least 62 bytes, but we need a check
    to prevent a read overflow.
    
    Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YMcoTPsCYlhh2TQo@mwanda
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ceb830e50c0ca144c3c3d087182a807538e8e22
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 14 12:55:35 2021 +0300

    staging: gdm724x: check for buffer overflow in gdm_lte_multi_sdu_pkt()
    
    [ Upstream commit 4a36e160856db8a8ddd6a3d2e5db5a850ab87f82 ]
    
    There needs to be a check to verify that we don't read beyond the end
    of "buf".  This function is called from do_rx().  The "buf" is the USB
    transfer_buffer and "len" is "urb->actual_length".
    
    Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Link: https://lore.kernel.org/r/YMcnl4zCwGWGDVMG@mwanda
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91664385e6c49f1e961e822f2d024776ac22102a
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jun 13 16:22:57 2021 +0100

    iio: adc: ti-ads8688: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 61fa5dfa5f52806f5ce37a0ba5712c271eb22f98 ]
    
    Add __aligned(8) to ensure the buffer passed to
    iio_push_to_buffers_with_timestamp() is suitable for the naturally
    aligned timestamp that will be inserted.
    
    Fixes: f214ff521fb1 ("iio: ti-ads8688: Update buffer allocation for timestamps")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210613152301.571002-5-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3e8164ccaebee06b6df3c7ad776bb69edd60ec4d
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jun 13 16:22:56 2021 +0100

    iio: adc: mxs-lradc: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 6a6be221b8bd561b053f0701ec752a5ed9007f69 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    Add a comment on why the buffer is the size it is as not immediately
    obvious.
    
    Found during an audit of all calls of this function.
    
    Fixes: 6dd112b9f85e ("iio: adc: mxs-lradc: Add support for ADC driver")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Andreas Klinger <ak@it-klinger.de>
    Reviewed-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210613152301.571002-4-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ce7cd150ef7821508c142f4755fe4c327f79df2
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sun Jun 13 16:22:55 2021 +0100

    iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit afe2a789fbf7acd1a05407fc7839cc08d23825e3 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: d3bf60450d47 ("iio: hx711: add triggered buffer support")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Andreas Klinger <ak@it-klinger.de>
    Reviewed-by: Nuno Sá <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210613152301.571002-3-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45c923bd692dc8280dbf79332b2cb6854365c41a
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Tue Jun 8 01:17:56 2021 +0300

    eeprom: idt_89hpesx: Restore printing the unsupported fwnode name
    
    [ Upstream commit e0db3deea73ba418bf5dc21f5a4e32ca87d16dde ]
    
    When iterating over child firmware nodes restore printing the name of ones
    that are not supported.
    
    While at it, refactor loop body to clearly show that we stop at the first match.
    
    Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
    Cc: Huy Duong <qhuyduong@hotmail.com>
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210607221757.81465-2-andy.shevchenko@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 286679fe8de3ccc8e6c56bdefec935767871e4d6
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Tue Jun 8 01:17:55 2021 +0300

    eeprom: idt_89hpesx: Put fwnode in matching case during ->probe()
    
    [ Upstream commit 3f6ee1c095156a74ab2df605af13020f1ce3e600 ]
    
    device_get_next_child_node() bumps a reference counting of a returned variable.
    We have to balance it whenever we return to the caller.
    
    Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing")
    Cc: Huy Duong <qhuyduong@hotmail.com>
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3842ed3642f3835d78a466232d07e25a0c6b42f1
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Thu May 27 17:24:20 2021 -0700

    s390: appldata depends on PROC_SYSCTL
    
    [ Upstream commit 5d3516b3647621d5a1180672ea9e0817fb718ada ]
    
    APPLDATA_BASE should depend on PROC_SYSCTL instead of PROC_FS.
    Building with PROC_FS but not PROC_SYSCTL causes a build error,
    since appldata_base.c uses data and APIs from fs/proc/proc_sysctl.c.
    
    arch/s390/appldata/appldata_base.o: in function `appldata_generic_handler':
    appldata_base.c:(.text+0x192): undefined reference to `sysctl_vals'
    
    Fixes: c185b783b099 ("[S390] Remove config options.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Heiko Carstens <hca@linux.ibm.com>
    Cc: Vasily Gorbik <gor@linux.ibm.com>
    Cc: Christian Borntraeger <borntraeger@de.ibm.com>
    Cc: linux-s390@vger.kernel.org
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Link: https://lore.kernel.org/r/20210528002420.17634-1-rdunlap@infradead.org
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 52147ba428ac4af703fe07b011f37f520a601c8d
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Fri May 28 16:26:14 2021 +0800

    visorbus: fix error return code in visorchipset_init()
    
    [ Upstream commit ce52ec5beecc1079c251f60e3973b3758f60eb59 ]
    
    Commit 1366a3db3dcf ("staging: unisys: visorbus: visorchipset_init clean
    up gotos") assigns the initial value -ENODEV to the local variable 'err',
    and the first several error branches will return this value after "goto
    error". But commit f1f537c2e7f5 ("staging: unisys: visorbus: Consolidate
    controlvm channel creation.") overwrites 'err' in the middle of the way.
    As a result, some error branches do not successfully return the initial
    value -ENODEV of 'err', but return 0.
    
    In addition, when kzalloc() fails, -ENOMEM should be returned instead of
    -ENODEV.
    
    Fixes: f1f537c2e7f5 ("staging: unisys: visorbus: Consolidate controlvm channel creation.")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210528082614.9337-1-thunder.leizhen@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d815623864fa979a76eab47deb245ebdaf234b65
Author: Joachim Fenkes <FENKES@de.ibm.com>
Date:   Fri Jul 24 16:45:18 2020 +0930

    fsi/sbefifo: Fix reset timeout
    
    [ Upstream commit 9ab1428dfe2c66b51e0b41337cd0164da0ab6080 ]
    
    On BMCs with lower timer resolution than 1ms, msleep(1) will take
    way longer than 1ms, so looping 10k times won't wait for 10s but
    significantly longer.
    
    Fix this by using jiffies like the rest of the code.
    
    Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
    Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
    Link: https://lore.kernel.org/r/20200724071518.430515-3-joel@jms.id.au
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 170674a2bead4c3e5148e6b5d0741262c3f5d028
Author: Joachim Fenkes <FENKES@de.ibm.com>
Date:   Fri Jul 24 16:45:17 2020 +0930

    fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE
    
    [ Upstream commit 95152433e46fdb36652ebdbea442356a16ae1fa6 ]
    
    When the SBE requests a reset via the down FIFO, that is also the
    FIFO we should go and reset ;)
    
    Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO")
    Signed-off-by: Joachim Fenkes <FENKES@de.ibm.com>
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20200724071518.430515-2-joel@jms.id.au
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9dda322a4c6b5f2f26af72f3da8d8c31b137b88b
Author: Eddie James <eajames@linux.ibm.com>
Date:   Mon Mar 29 10:13:44 2021 -0500

    fsi: scom: Reset the FSI2PIB engine for any error
    
    [ Upstream commit a5c317dac5567206ca7b6bc9d008dd6890c8bced ]
    
    The error bits in the FSI2PIB status are only cleared by a reset. So
    the driver needs to perform a reset after seeing any of the FSI2PIB
    errors, otherwise subsequent operations will also look like failures.
    
    Fixes: 6b293258cded ("fsi: scom: Major overhaul")
    Signed-off-by: Eddie James <eajames@linux.ibm.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Link: https://lore.kernel.org/r/20210329151344.14246-1-eajames@linux.ibm.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2937821a8ea8b78ea57693e50f7cf78333657d4
Author: Colin Ian King <colin.king@canonical.com>
Date:   Thu Jun 3 13:28:12 2021 +0100

    fsi: core: Fix return of error values on failures
    
    [ Upstream commit 910810945707fe9877ca86a0dca4e585fd05e37b ]
    
    Currently the cfam_read and cfam_write functions return the provided
    number of bytes given in the count parameter and not the error return
    code in variable rc, hence all failures of read/writes are being
    silently ignored. Fix this by returning the error code in rc.
    
    Addresses-Coverity: ("Unused value")
    Fixes: d1dcd6782576 ("fsi: Add cfam char devices")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Reviewed-by: Jeremy Kerr <jk@ozlabs.org>
    Link: https://lore.kernel.org/r/20210603122812.83587-1-colin.king@canonical.com
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b71c5f0c2f21676d13c19a737c8423d764df4ab1
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat May 29 16:48:57 2021 -0700

    scsi: FlashPoint: Rename si_flags field
    
    [ Upstream commit 4d431153e751caa93f3b7e6f6313446974e92253 ]
    
    The BusLogic driver has build errors on ia64 due to a name collision (in
    the #included FlashPoint.c file). Rename the struct field in struct
    sccb_mgr_info from si_flags to si_mflags (manager flags) to mend the build.
    
    This is the first problem. There are 50+ others after this one:
    
    In file included from ../include/uapi/linux/signal.h:6,
                     from ../include/linux/signal_types.h:10,
                     from ../include/linux/sched.h:29,
                     from ../include/linux/hardirq.h:9,
                     from ../include/linux/interrupt.h:11,
                     from ../drivers/scsi/BusLogic.c:27:
    ../arch/ia64/include/uapi/asm/siginfo.h:15:27: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token
       15 | #define si_flags _sifields._sigfault._flags
          |                           ^
    ../drivers/scsi/FlashPoint.c:43:6: note: in expansion of macro 'si_flags'
       43 |  u16 si_flags;
          |      ^~~~~~~~
    In file included from ../drivers/scsi/BusLogic.c:51:
    ../drivers/scsi/FlashPoint.c: In function 'FlashPoint_ProbeHostAdapter':
    ../drivers/scsi/FlashPoint.c:1076:11: error: 'struct sccb_mgr_info' has no member named '_sifields'
     1076 |  pCardInfo->si_flags = 0x0000;
          |           ^~
    ../drivers/scsi/FlashPoint.c:1079:12: error: 'struct sccb_mgr_info' has no member named '_sifields'
    
    Link: https://lore.kernel.org/r/20210529234857.6870-1-rdunlap@infradead.org
    Fixes: 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit.")
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Khalid Aziz <khalid.aziz@oracle.com>
    Cc: Khalid Aziz <khalid@gonehiking.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffcdf486f380f4e4a7152294c0c9c4fb5fe53d0b
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Tue May 25 20:51:57 2021 +0200

    tty: nozomi: Fix the error handling path of 'nozomi_card_init()'
    
    [ Upstream commit 6ae7d0f5a92b9619f6e3c307ce56b2cefff3f0e9 ]
    
    The error handling path is broken and we may un-register things that have
    never been registered.
    
    Update the loops index accordingly.
    
    Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result")
    Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/e28c2e92c7475da25b03d022ea2d6dcf1ba807a2.1621968629.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 813790e3d2a0eaa00e0617325b1b670ac6ac39ef
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Fri May 21 20:06:17 2021 +0800

    char: pcmcia: error out if 'num_bytes_read' is greater than 4 in set_protocol()
    
    [ Upstream commit 37188559c610f1b7eec83c8e448936c361c578de ]
    
    Theoretically, it will cause index out of bounds error if
    'num_bytes_read' is greater than 4. As we expect it(and was tested)
    never to be greater than 4, error out if it happens.
    
    Fixes: c1986ee9bea3 ("[PATCH] New Omnikey Cardman 4000 driver")
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20210521120617.138396-1-yukuai3@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 61375cb1115948165697945ab2dd290caf72be8e
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Mon May 24 11:52:42 2021 -0700

    Input: hil_kbd - fix error return code in hil_dev_connect()
    
    [ Upstream commit d9b576917a1d0efa293801a264150a1b37691617 ]
    
    Return error code -EINVAL rather than '0' when the combo devices are not
    supported.
    
    Fixes: fa71c605c2bb ("Input: combine hil_kbd and hil_ptr drivers")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210515030053.6824-1-thunder.leizhen@huawei.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b52a9dec111c2416278a445785b98974aa55fabe
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Mon May 24 15:12:09 2021 +0900

    ASoC: rsnd: tidyup loop on rsnd_adg_clk_query()
    
    [ Upstream commit cf9d5c6619fadfc41cf8f5154cb990cc38e3da85 ]
    
    commit 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under
    atomic context") used saved clk_rate, thus for_each_rsnd_clk()
    is no longer needed. This patch fixes it.
    
    Fixes: 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under atomic context")
    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/87v978oe2u.wl-kuninori.morimoto.gx@renesas.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e784b66299dd9fa764d4969ca987493e14597534
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue May 18 12:45:14 2021 +0800

    ASoC: hisilicon: fix missing clk_disable_unprepare() on error in hi6210_i2s_startup()
    
    [ Upstream commit 375904e3931955fcf0a847f029b2492a117efc43 ]
    
    After calling clk_prepare_enable(), clk_disable_unprepare() need
    be called when calling clk_set_rate() failed.
    
    Fixes: 0bf750f4cbe1 ("ASoC: hisilicon: Add hi6210 i2s audio driver")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210518044514.607010-1-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51ef21934d1cc8e8af434a3d8429baeb41a4a91f
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:13:48 2021 +0100

    iio: potentiostat: lmp91000: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 8979b67ec61abc232636400ee8c758a16a73c95f ]
    
    Add __aligned(8) to ensure the buffer passed to
    iio_push_to_buffers_with_timestamp() is suitable for the naturally
    aligned timestamp that will be inserted.
    
    Here structure is not used, because this buffer is also used
    elsewhere in the driver.
    
    Fixes: 67e17300dc1d ("iio: potentiostat: add LMP91000 support")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Matt Ranostay <matt.ranostay@konsulko.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Link: https://lore.kernel.org/r/20210501171352.512953-8-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f3a5bf2b0bf9062b8ac35de522776da85e6a5622
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:21 2021 +0100

    iio: light: tcs3472: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit df2f37cffd6ed486d613e7ee22aadc8e49ae2dd3 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp().
    
    Fixes tag is not strictly accurate as prior to that patch there was
    potentially an unaligned write.  However, any backport past there will
    need to be done manually.
    
    Fixes: 0624bf847dd0 ("iio:tcs3472: Use iio_push_to_buffers_with_timestamp()")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-20-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a11f9d098e92eb34144eba62aeead67ba47849b
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:20 2021 +0100

    iio: light: tcs3414: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit ff08fbc22ab32ccc6690c21b0e5e1d402dcc076f ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: a244e7b57f0f ("iio: Add driver for AMS/TAOS tcs3414 digital color sensor")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-19-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8111e6295f59e9d58fc4ae03b1156b30438296cc
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:19 2021 +0100

    iio: light: isl29125: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 3d4725194de6935dba2ad7c9cc075c885008f747 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 6c25539cbc46 ("iio: Add Intersil isl29125 digital color light sensor driver")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-18-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b27970a4e01803ab76181d7dd0069148d55469fa
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:16 2021 +0100

    iio: prox: as3935: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 37eb8d8c64f2ecb3a5521ba1cc1fad973adfae41 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 37b1ba2c68cf ("iio: proximity: as3935: fix buffer stack trashing")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Matt Ranostay <matt.ranostay@konsulko.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-15-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9f98de0e407699ad9b7c7ee733525c787800ae5b
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:15 2021 +0100

    iio: prox: pulsed-light: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 679cc377a03ff1944491eafc7355c1eb1fad4109 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: cb119d535083 ("iio: proximity: add support for PulsedLight LIDAR")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Matt Ranostay <matt.ranostay@konsulko.com>
    Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-14-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0fc539968b28b956df24bc209cdabac00886d46c
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:14 2021 +0100

    iio: prox: srf08: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 19f1a254fe4949fff1e67db386409f48cf438bd7 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Andreas Klinger <ak@it-klinger.de>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-13-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 578a2530ef2b2bf3e98ae0bfcabf2dd7b59913c6
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:13 2021 +0100

    iio: humidity: am2315: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit f4ca2e2595d9fee65d5ce0d218b22ce00e5b2915 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 0d96d5ead3f7 ("iio: humidity: Add triggered buffer support for AM2315")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-12-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7db658caefcf92270c834db7b2126c22ae54109
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:12 2021 +0100

    iio: gyro: bmg160: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 06778d881f3798ce93ffbbbf801234292250b598 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 13426454b649 ("iio: bmg160: Separate i2c and core driver")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Stephan Gerhold <stephan@gerhold.net>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-11-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit df848efb61dd2a2886d1c03269e2205d269cee72
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:11 2021 +0100

    iio: adc: vf610: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 7765dfaa22ea08abf0c175e7553826ba2a939632 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of uses of
    iio_push_to_buffers_with_timestamp()
    
    Fixes: 0010d6b44406 ("iio: adc: vf610: Add IIO buffer support for Vybrid ADC")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
    Cc: Sanchayan Maity <maitysanchayan@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-10-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0d27f41be7bd2b9ffd775cec91aff906bfbfcb8
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:10 2021 +0100

    iio: adc: ti-ads1015: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit d85d71dd1ab67eaa7351f69fec512d8f09d164e1 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Daniel Baluta <daniel.baluta@nxp.com>
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-9-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3ffec10f9bd0c91a3c5dbbe2ad3b371c8013dfd3
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:09 2021 +0100

    iio: accel: stk8ba50: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 334883894bc1e145a1e0f5de1b0d1b6a1133f0e6 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: db6a19b8251f ("iio: accel: Add trigger support for STK8BA50")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-8-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3e25a6561653cab351d20f285e3e4fb2bf517c4
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:08 2021 +0100

    iio: accel: stk8312: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit f40a71ffec808e7e51848f63f0c0d3c32d65081b ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: 95c12bba51c3 ("iio: accel: Add buffer mode for Sensortek STK8312")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-7-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aaf8b88d3f34651122c88e1c9d9a7cd8d6895ebc
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:06 2021 +0100

    iio: accel: kxcjk-1013: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 3ab3aa2e7bd57497f9a7c6275c00dce237d2c9ba ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: 1a4fbf6a9286 ("iio: accel: kxcjk1013 3-axis accelerometer driver")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-5-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ede0436891bfa39711bb0488a28d9cc3db0c14d2
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:05 2021 +0100

    iio: accel: hid: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit c6559bf796ccdb3a0c79db846af96c8f7046880b ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    Note this matches what was done in all the other hid sensor drivers.
    This one was missed previously due to an extra level of indirection.
    
    Found during an audit of all calls of this function.
    
    Fixes: a96cd0f901ee ("iio: accel: hid-sensor-accel-3d: Add timestamp")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-4-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 64e79e553e5200e077222db8cdb5272440a7d48d
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:04 2021 +0100

    iio: accel: bma220: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit 151dbf0078da98206817ee0b87d499035479ef11 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: 194dc4c71413 ("iio: accel: Add triggered buffer support for BMA220")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-3-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 86a5292e0c50076146c21db3c4c9fb8bd24b5d96
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Sat May 1 18:01:03 2021 +0100

    iio: accel: bma180: Fix buffer alignment in iio_push_to_buffers_with_timestamp()
    
    [ Upstream commit fc36da3131a747a9367a05caf06de19be1bcc972 ]
    
    To make code more readable, use a structure to express the channel
    layout and ensure the timestamp is 8 byte aligned.
    
    Found during an audit of all calls of this function.
    
    Fixes: b9a6a237ffc9 ("iio:bma180: Drop _update_scan_mode()")
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Cc: Peter Meerwald <pmeerw@pmeerw.net>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Link: https://lore.kernel.org/r/20210501170121.512209-2-jic23@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bf349ef02dad548b93e050e90da616b7ed7a59bd
Author: Nuno Sa <nuno.sa@analog.com>
Date:   Thu Apr 22 12:19:03 2021 +0200

    iio: adis_buffer: do not return ints in irq handlers
    
    [ Upstream commit d877539ad8e8fdde9af69887055fec6402be1a13 ]
    
    On an IRQ handler we should not return normal error codes as 'irqreturn_t'
    is expected.
    
    Not necessarily stable material as the old check cannot fail, so it's a bug
    we can not hit.
    
    Fixes: ccd2b52f4ac69 ("staging:iio: Add common ADIS library")
    Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
    Signed-off-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20210422101911.135630-2-nuno.sa@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d8a385de3749c77767cd0d9fc8a4427dc87fffa
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sat May 8 00:07:55 2021 +0200

    mwifiex: re-fix for unaligned accesses
    
    [ Upstream commit 8f4e3d48bb50765ab27ae5bebed2595b20de80a1 ]
    
    A patch from 2017 changed some accesses to DMA memory to use
    get_unaligned_le32() and similar interfaces, to avoid problems
    with doing unaligned accesson uncached memory.
    
    However, the change in the mwifiex_pcie_alloc_sleep_cookie_buf()
    function ended up changing the size of the access instead,
    as it operates on a pointer to u8.
    
    Change this function back to actually access the entire 32 bits.
    Note that the pointer is aligned by definition because it came
    from dma_alloc_coherent().
    
    Fixes: 92c70a958b0b ("mwifiex: fix for unaligned reads")
    Acked-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23e431f7f36cb2744be7f1a1fffe6a3608b21b0c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun May 9 19:22:33 2021 +0200

    tty: nozomi: Fix a resource leak in an error handling function
    
    [ Upstream commit 31a9a318255960d32ae183e95d0999daf2418608 ]
    
    A 'request_irq()' call is not balanced by a corresponding 'free_irq()' in
    the error handling path, as already done in the remove function.
    
    Add it.
    
    Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result")
    Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/4f0d2b3038e82f081d370ccb0cade3ad88463fe7.1620580838.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ccc59418ad81e6fa24ee50f4adc763f12972ce2c
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Jun 29 11:51:38 2021 +0300

    RDMA/mlx5: Don't access NULL-cleared mpi pointer
    
    [ Upstream commit 4a754d7637026b42b0c9ba5787ad5ee3bc2ff77f ]
    
    The "dev->port[i].mp.mpi" is set to NULL during mlx5_ib_unbind_slave_port()
    execution, however that field is needed to add device to unaffiliated list.
    
    Such flow causes to the following kernel panic while unloading mlx5_ib
    module in multi-port mode, hence the device should be added to the list
    prior to unbind call.
    
     RPC: Unregistered rdma transport module.
     RPC: Unregistered rdma backchannel transport module.
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 0 P4D 0
     Oops: 0002 [#1] SMP NOPTI
     CPU: 4 PID: 1904 Comm: modprobe Not tainted 5.13.0-rc7_for_upstream_min_debug_2021_06_24_12_08 #1
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
     RIP: 0010:mlx5_ib_cleanup_multiport_master+0x18b/0x2d0 [mlx5_ib]
     Code: 00 04 0f 85 c4 00 00 00 48 89 df e8 ef fa ff ff 48 8b 83 40 0d 00 00 48 8b 15 b9 e8 05 00 4a 8b 44 28 20 48 89 05 ad e8 05 00 <48> c7 00 d0 57 c5 a0 48 89 50 08 48 89 02 39 ab 88 0a 00 00 0f 86
     RSP: 0018:ffff888116ee3df8 EFLAGS: 00010296
     RAX: 0000000000000000 RBX: ffff8881154f6000 RCX: 0000000000000080
     RDX: ffffffffa0c557d0 RSI: ffff88810b69d200 RDI: 000000000002d8a0
     RBP: 0000000000000002 R08: ffff888110780408 R09: 0000000000000000
     R10: ffff88812452e1c0 R11: fffffffffff7e028 R12: 0000000000000000
     R13: 0000000000000080 R14: ffff888102c58000 R15: 0000000000000000
     FS:  00007f884393a740(0000) GS:ffff8882f5a00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 00000001249f6004 CR4: 0000000000370ea0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      mlx5_ib_stage_init_cleanup+0x16/0xd0 [mlx5_ib]
      __mlx5_ib_remove+0x33/0x90 [mlx5_ib]
      mlx5r_remove+0x22/0x30 [mlx5_ib]
      auxiliary_bus_remove+0x18/0x30
      __device_release_driver+0x177/0x220
      driver_detach+0xc4/0x100
      bus_remove_driver+0x58/0xd0
      auxiliary_driver_unregister+0x12/0x20
      mlx5_ib_cleanup+0x13/0x897 [mlx5_ib]
      __x64_sys_delete_module+0x154/0x230
      ? exit_to_user_mode_prepare+0x104/0x140
      do_syscall_64+0x3f/0x80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7f8842e095c7
     Code: 73 01 c3 48 8b 0d d9 48 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 48 2c 00 f7 d8 64 89 01 48
     RSP: 002b:00007ffc68f6e758 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
     RAX: ffffffffffffffda RBX: 00005638207929c0 RCX: 00007f8842e095c7
     RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000563820792a28
     RBP: 00005638207929c0 R08: 00007ffc68f6d701 R09: 0000000000000000
     R10: 00007f8842e82880 R11: 0000000000000206 R12: 0000563820792a28
     R13: 0000000000000001 R14: 0000563820792a28 R15: 00007ffc68f6fb40
     Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter overlay rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_ipoib ib_cm ib_umad mlx5_ib(-) mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core mlx5_core ptp pps_core [last unloaded: rpcrdma]
     CR2: 0000000000000000
     ---[ end trace a0bb7e20804e9e9b ]---
    
    Fixes: 7ce6095e3bff ("RDMA/mlx5: Don't add slave port to unaffiliated list")
    Link: https://lore.kernel.org/r/899ac1b33a995be5ec0e16a4765c4e43c2b1ba5b.1624956444.git.leonro@nvidia.com
    Reviewed-by: Itay Aveksis <itayav@nvidia.com>
    Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc18600633edcbce901f8eae82fa0d237aee4b42
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Jun 25 23:23:48 2021 +0300

    net: sched: fix warning in tcindex_alloc_perfect_hash
    
    [ Upstream commit 3f2db250099f46988088800052cdf2332c7aba61 ]
    
    Syzbot reported warning in tcindex_alloc_perfect_hash. The problem
    was in too big cp->hash, which triggers warning in kmalloc. Since
    cp->hash comes from userspace, there is no need to warn if value
    is not correct
    
    Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()")
    Reported-and-tested-by: syzbot+1071ad60cd7df39fdadb@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Acked-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d76613a914b1950604bdcec2a44f4557ff42c65d
Author: Vadim Fedorenko <vfedorenko@novek.ru>
Date:   Fri Jun 25 19:21:39 2021 +0300

    net: lwtunnel: handle MTU calculation in forwading
    
    [ Upstream commit fade56410c22cacafb1be9f911a0afd3701d8366 ]
    
    Commit 14972cbd34ff ("net: lwtunnel: Handle fragmentation") moved
    fragmentation logic away from lwtunnel by carry encap headroom and
    use it in output MTU calculation. But the forwarding part was not
    covered and created difference in MTU for output and forwarding and
    further to silent drops on ipv4 forwarding path. Fix it by taking
    into account lwtunnel encap headroom.
    
    The same commit also introduced difference in how to treat RTAX_MTU
    in IPv4 and IPv6 where latter explicitly removes lwtunnel encap
    headroom from route MTU. Make IPv4 version do the same.
    
    Fixes: 14972cbd34ff ("net: lwtunnel: Handle fragmentation")
    Suggested-by: David Ahern <dsahern@gmail.com>
    Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdf3ef3f66cb88f30fbf9396f876937b29506d9b
Author: Muchun Song <songmuchun@bytedance.com>
Date:   Fri Apr 2 17:11:45 2021 +0800

    writeback: fix obtain a reference to a freeing memcg css
    
    [ Upstream commit 8b0ed8443ae6458786580d36b7d5f8125535c5d4 ]
    
    The caller of wb_get_create() should pin the memcg, because
    wb_get_create() relies on this guarantee. The rcu read lock
    only can guarantee that the memcg css returned by css_from_id()
    cannot be released, but the reference of the memcg can be zero.
    
      rcu_read_lock()
      memcg_css = css_from_id()
      wb_get_create(memcg_css)
          cgwb_create(memcg_css)
              // css_get can change the ref counter from 0 back to 1
              css_get(memcg_css)
      rcu_read_unlock()
    
    Fix it by holding a reference to the css before calling
    wb_get_create(). This is not a problem I encountered in the
    real world. Just the result of a code review.
    
    Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates")
    Link: https://lore.kernel.org/r/20210402091145.80635-1-songmuchun@bytedance.com
    Signed-off-by: Muchun Song <songmuchun@bytedance.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a808634e5a6eb74eb7423cb999c1892a5c7b547
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Jun 22 20:59:02 2021 -0700

    Bluetooth: Fix handling of HCI_LE_Advertising_Set_Terminated event
    
    [ Upstream commit 23837a6d7a1a61818ed94a6b8af552d6cf7d32d5 ]
    
    Error status of this event means that it has ended due reasons other
    than a connection:
    
     'If advertising has terminated as a result of the advertising duration
     elapsing, the Status parameter shall be set to the error code
     Advertising Timeout (0x3C).'
    
     'If advertising has terminated because the
     Max_Extended_Advertising_Events was reached, the Status parameter
     shall be set to the error code Limit Reached (0x43).'
    
    Fixes: acf0aeae431a0 ("Bluetooth: Handle ADv set terminated event")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 40a7196f31caec156c7a8346850eaf3614289a69
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri May 28 11:45:02 2021 -0700

    Bluetooth: mgmt: Fix slab-out-of-bounds in tlv_data_is_valid
    
    [ Upstream commit 799acb9347915bfe4eac0ff2345b468f0a1ca207 ]
    
    This fixes parsing of LTV entries when the length is 0.
    
    Found with:
    
    tools/mgmt-tester -s "Add Advertising - Success (ScRsp only)"
    
    Add Advertising - Success (ScRsp only) - run
      Sending Add Advertising (0x003e)
      Test condition added, total 1
    [   11.004577] ==================================================================
    [   11.005292] BUG: KASAN: slab-out-of-bounds in tlv_data_is_valid+0x87/0xe0
    [   11.005984] Read of size 1 at addr ffff888002c695b0 by task mgmt-tester/87
    [   11.006711]
    [   11.007176]
    [   11.007429] Allocated by task 87:
    [   11.008151]
    [   11.008438] The buggy address belongs to the object at ffff888002c69580
    [   11.008438]  which belongs to the cache kmalloc-64 of size 64
    [   11.010526] The buggy address is located 48 bytes inside of
    [   11.010526]  64-byte region [ffff888002c69580, ffff888002c695c0)
    [   11.012423] The buggy address belongs to the page:
    [   11.013291]
    [   11.013544] Memory state around the buggy address:
    [   11.014359]  ffff888002c69480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [   11.015453]  ffff888002c69500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [   11.016232] >ffff888002c69580: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
    [   11.017010]                                      ^
    [   11.017547]  ffff888002c69600: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
    [   11.018296]  ffff888002c69680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
    [   11.019116] ==================================================================
    
    Fixes: 2bb36870e8cb2 ("Bluetooth: Unify advertising instance flags check")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c7a0c308b3ac149ab6e4a86c7b9bc9ffce6154e
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 24 03:07:20 2021 -0700

    ipv6: fix out-of-bound access in ip6_parse_tlv()
    
    [ Upstream commit 624085a31c1ad6a80b1e53f686bf6ee92abbf6e8 ]
    
    First problem is that optlen is fetched without checking
    there is more than one byte to parse.
    
    Fix this by taking care of IPV6_TLV_PAD1 before
    fetching optlen (under appropriate sanity checks against len)
    
    Second problem is that IPV6_TLV_PADN checks of zero
    padding are performed before the check of remaining length.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Fixes: c1412fce7ecc ("net/ipv6/exthdrs.c: Strict PadN option checking")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Tom Herbert <tom@herbertland.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4194876ced7c141d03791a0a1b57e575cf218c3b
Author: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Date:   Wed Jun 23 21:13:15 2021 -0700

    ibmvnic: free tx_pool if tso_pool alloc fails
    
    [ Upstream commit f6ebca8efa52e4ae770f0325d618e7bcf08ada0c ]
    
    Free tx_pool and clear it, if allocation of tso_pool fails.
    
    release_tx_pools() assumes we have both tx and tso_pools if ->tx_pool is
    non-NULL. If allocation of tso_pool fails in init_tx_pools(), the assumption
    will not be true and we would end up dereferencing ->tx_buff, ->free_map
    fields from a NULL pointer.
    
    Fixes: 3205306c6b8d ("ibmvnic: Update TX pool initialization routine")
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83098421509eba10ab8f0dc62761e4a70887079b
Author: Dany Madden <drt@linux.ibm.com>
Date:   Wed Jun 23 21:13:11 2021 -0700

    Revert "ibmvnic: remove duplicate napi_schedule call in open function"
    
    [ Upstream commit 2ca220f92878470c6ba03f9946e412323093cc94 ]
    
    This reverts commit 7c451f3ef676c805a4b77a743a01a5c21a250a73.
    
    When a vnic interface is taken down and then up, connectivity is not
    restored. We bisected it to this commit. Reverting this commit until
    we can fully investigate the issue/benefit of the change.
    
    Fixes: 7c451f3ef676 ("ibmvnic: remove duplicate napi_schedule call in open function")
    Reported-by: Cristobal Forno <cforno12@linux.ibm.com>
    Reported-by: Abdul Haleem <abdhalee@in.ibm.com>
    Signed-off-by: Dany Madden <drt@linux.ibm.com>
    Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ac2abd4eec77810b28a77ede662cca7e10dd73cd
Author: Mateusz Palczewski <mateusz.palczewski@intel.com>
Date:   Wed Mar 10 11:12:54 2021 +0000

    i40e: Fix autoneg disabling for non-10GBaseT links
    
    [ Upstream commit 9262793e59f0423437166a879a73d056b1fe6f9a ]
    
    Disabling autonegotiation was allowed only for 10GBaseT PHY.
    The condition was changed to check if link media type is BaseT.
    
    Fixes: 3ce12ee9d8f9 ("i40e: Fix order of checks when enabling/disabling autoneg in ethtool")
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Karen Sornek <karen.sornek@intel.com>
    Signed-off-by: Dawid Lukwinski <dawid.lukwinski@intel.com>
    Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fdb69fdf4fe8ffcaad0ba0ad3608526ba798f6dd
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sun Feb 28 19:50:58 2021 +0800

    i40e: Fix error handling in i40e_vsi_open
    
    [ Upstream commit 9c04cfcd4aad232e36306cdc5c74cd9fc9148a7e ]
    
    When vsi->type == I40E_VSI_FDIR, we have caught the return value of
    i40e_vsi_request_irq() but without further handling. Check and execute
    memory clean on failure just like the other i40e_vsi_request_irq().
    
    Fixes: 8a9eb7d3cbcab ("i40e: rework fdir setup and teardown")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c557d06b420b08e380e2875f04aff8624fb8dcc
Author: Maciej Żenczykowski <maze@google.com>
Date:   Wed Jun 16 17:09:51 2021 -0700

    bpf: Do not change gso_size during bpf_skb_change_proto()
    
    [ Upstream commit 364745fbe981a4370f50274475da4675661104df ]
    
    This is technically a backwards incompatible change in behaviour, but I'm
    going to argue that it is very unlikely to break things, and likely to fix
    *far* more then it breaks.
    
    In no particular order, various reasons follow:
    
    (a) I've long had a bug assigned to myself to debug a super rare kernel crash
    on Android Pixel phones which can (per stacktrace) be traced back to BPF clat
    IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later
    on during transmit deep in the GSO engine, AFAICT precisely because of this
    change to gso_size, though I've never been able to manually reproduce it. I
    believe it may be related to the particular network offload support of attached
    USB ethernet dongle being used for tethering off of an IPv6-only cellular
    connection. The reason might be we end up with more segments than max permitted,
    or with a GSO packet with only one segment... (either way we break some
    assumption and hit a BUG_ON)
    
    (b) There is no check that the gso_size is > 20 when reducing it by 20, so we
    might end up with a negative (or underflowing) gso_size or a gso_size of 0.
    This can't possibly be good. Indeed this is probably somehow exploitable (or
    at least can result in a kernel crash) by delivering crafted packets and perhaps
    triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS)
    is related to MTU, but not directly derived from it: gso_size/MSS may be
    significantly smaller then one would get by deriving from local MTU. And on
    some NICs (which do loose MTU checking on receive, it may even potentially be
    larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and
    sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just
    going from 21 to 1 is potentially problematic because it increases the number
    of segments by a factor of 21 (think DoS, or some other crash due to too many
    segments).
    
    (c) It's always safe to not increase the gso_size, because it doesn't result in
    the max packet size increasing.  So the skb_increase_gso_size() call was always
    unnecessary for correctness (and outright undesirable, see later). As such the
    only part which is potentially dangerous (ie. could cause backwards compatibility
    issues) is the removal of the skb_decrease_gso_size() call.
    
    (d) If the packets are ultimately destined to the local device, then there is
    absolutely no benefit to playing around with gso_size. It only matters if the
    packets will egress the device. ie. we're either forwarding, or transmitting
    from the device.
    
    (e) This logic only triggers for packets which are GSO. It does not trigger for
    skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a
    GSO packet (and you don't even know what the MTU is, so you can't even fix it).
    As such your transmit path must *already* be able to handle an MTU 20 bytes
    larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28
    bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size()
    call doesn't actually increase the size of the packets your transmit side must
    be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/
    route MTUs must already be set correctly. Since for example with an IPv4 egress
    MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames,
    so you need a 1520 byte device MTU. This means if your IPv6 device's egress
    MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the
    need to handle fragments). This is to handle normal non-GSO packets. Thus the
    reduction is simply not needed for GSO packets, because when they're correctly
    built, they will already be the right size.
    
    (f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP
    segments) should not be modified, so that TCP's MSS counting works correctly
    (this matters for congestion control). If protocol conversion changes the
    gso_size, then the number of TCP segments may increase or decrease. Packet loss
    after protocol conversion can result in partial loss of MSS segments that the
    sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs
    in the middle of the segments it sent?
    
    (g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS
    case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee
    that gso_size (and thus resulting packet MTU) is changed. ie. you must assume
    it won't be changed.
    
    (h) changing gso_size is outright buggy for UDP GSO packets, where framing
    matters (I believe that's also the case for SCTP, but it's already excluded
    by [g]).  So the only remaining case is TCP, which also doesn't want it
    (see [f]).
    
    (i) see also the reasoning on the previous attempt at fixing this
    (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current
    behaviour causes TCP packet loss:
    
      In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the
      coalesced packet payload can be > MSS, but < MSS + 20.
    
      bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload
      length. After then tcp_gso_segment checks for the payload length if it
      is <= MSS. The condition is causing the packet to be dropped.
    
      tcp_gso_segment():
        [...]
        mss = skb_shinfo(skb)->gso_size;
        if (unlikely(skb->len <= mss)) goto out;
        [...]
    
    Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary
    and buggy, and decreasing can go negative.
    
    Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Dongseok Yi <dseok.yi@samsung.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com
    Link: https://lore.kernel.org/bpf/20210617000953.2787453-2-zenczykowski@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d317a20a84c434ae0a2011e551e6f400b995c32e
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Jun 23 08:27:00 2021 -0700

    ipv6: exthdrs: do not blindly use init_net
    
    [ Upstream commit bcc3f2a829b9edbe3da5fb117ee5a63686d31834 ]
    
    I see no reason why max_dst_opts_cnt and max_hbh_opts_cnt
    are fetched from the initial net namespace.
    
    The other sysctls (max_dst_opts_len & max_hbh_opts_len)
    are in fact already using the current ns.
    
    Note: it is not clear why ipv6_destopt_rcv() use two ways to
    get to the netns :
    
     1) dev_net(dst->dev)
        Originally used to increment IPSTATS_MIB_INHDRERRORS
    
     2) dev_net(skb->dev)
         Tom used this variant in his patch.
    
    Maybe this calls to use ipv6_skb_net() instead ?
    
    Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Tom Herbert <tom@quantonium.net>
    Cc: Coco Li <lixiaoyan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8d4032690ae961cf8a8ce7b8da7a5fdb84f5e470
Author: Jian-Hong Pan <jhp@endlessos.org>
Date:   Wed Jun 23 11:28:03 2021 +0800

    net: bcmgenet: Fix attaching to PYH failed on RPi 4B
    
    [ Upstream commit b2ac9800cfe0f8da16abc4e74e003440361c112e ]
    
    The Broadcom UniMAC MDIO bus from mdio-bcm-unimac module comes too late.
    So, GENET cannot find the ethernet PHY on UniMAC MDIO bus. This leads
    GENET fail to attach the PHY as following log:
    
    bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
    ...
    could not attach to PHY
    bcmgenet fd580000.ethernet eth0: failed to connect to PHY
    uart-pl011 fe201000.serial: no DMA platform data
    libphy: bcmgenet MII bus: probed
    ...
    unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
    
    This patch adds the soft dependency to load mdio-bcm-unimac module
    before genet module to avoid the issue.
    
    Fixes: 9a4e79697009 ("net: bcmgenet: utilize generic Broadcom UniMAC MDIO controller driver")
    Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=213485
    Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f001552df5e3e183ed80e1fc60fcbd7698b0904
Author: Ping-Ke Shih <pkshih@realtek.com>
Date:   Wed Jun 23 21:48:25 2021 +0800

    mac80211: remove iwlwifi specific workaround NDPs of null_response
    
    [ Upstream commit 744757e46bf13ec3a7b3507d17ab3faab9516d43 ]
    
    Remove the remaining workaround that is not removed by the
    commit e41eb3e408de ("mac80211: remove iwlwifi specific workaround
    that broke sta NDP tx")
    
    Fixes: 41cbb0f5a295 ("mac80211: add support for HE")
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://lore.kernel.org/r/20210623134826.10318-1-pkshih@realtek.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 567001688c862158318557a9bd03b6c077c3392a
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 21 11:02:44 2021 -0700

    ieee802154: hwsim: avoid possible crash in hwsim_del_edge_nl()
    
    [ Upstream commit 0303b30375dff5351a79cc2c3c87dfa4fda29bed ]
    
    Both MAC802154_HWSIM_ATTR_RADIO_ID and MAC802154_HWSIM_ATTR_RADIO_EDGE
    must be present to avoid a crash.
    
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Aring <alex.aring@gmail.com>
    Cc: Stefan Schmidt <stefan@datenfreihafen.org>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210621180244.882076-1-eric.dumazet@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d8dcd49ddd9665580237a639266be63c8567f26
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Wed Jun 16 10:09:01 2021 +0800

    ieee802154: hwsim: Fix memory leak in hwsim_add_one
    
    [ Upstream commit 28a5501c3383f0e6643012c187b7c2027ef42aea ]
    
    No matter from hwsim_remove or hwsim_del_radio_nl, hwsim_del fails to
    remove the entry in the edges list. Take the example below, phy0, phy1
    and e0 will be deleted, resulting in e1 not freed and accessed in the
    future.
    
                  hwsim_phys
                      |
        ------------------------------
        |                            |
    phy0 (edges)                 phy1 (edges)
       ----> e1 (idx = 1)             ----> e0 (idx = 0)
    
    Fix this by deleting and freeing all the entries in the edges list
    between hwsim_edge_unsubscribe_me and list_del(&phy->list).
    
    Reported-by: syzbot+b80c9959009a9325cdff@syzkaller.appspotmail.com
    Fixes: 1c9f4a3fce77 ("ieee802154: hwsim: fix rcu handling")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210616020901.2759466-1-mudongliangabcd@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cb6b100b869164dcd4b48e8c236e0a9f1c8c0ad
Author: Miao Wang <shankerwangmiao@gmail.com>
Date:   Tue Jun 22 12:24:50 2021 +0800

    net/ipv4: swap flow ports when validating source
    
    [ Upstream commit c69f114d09891adfa3e301a35d9e872b8b7b5a50 ]
    
    When doing source address validation, the flowi4 struct used for
    fib_lookup should be in the reverse direction to the given skb.
    fl4_dport and fl4_sport returned by fib4_rules_early_flow_dissect
    should thus be swapped.
    
    Fixes: 5a847a6e1477 ("net/ipv4: Initialize proto and ports in flow struct")
    Signed-off-by: Miao Wang <shankerwangmiao@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f80201ff7937fddb039716ba5948775b485d7646
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 21 07:44:17 2021 -0700

    vxlan: add missing rcu_read_lock() in neigh_reduce()
    
    [ Upstream commit 85e8b032d6ebb0f698a34dd22c2f13443d905888 ]
    
    syzbot complained in neigh_reduce(), because rcu_read_lock_bh()
    is treated differently than rcu_read_lock()
    
    WARNING: suspicious RCU usage
    5.13.0-rc6-syzkaller #0 Not tainted
    -----------------------------
    include/net/addrconf.h:313 suspicious rcu_dereference_check() usage!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 1
    3 locks held by kworker/0:0/5:
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:617 [inline]
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
     #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x871/0x1600 kernel/workqueue.c:2247
     #1: ffffc90000ca7da8 ((work_completion)(&port->wq)){+.+.}-{0:0}, at: process_one_work+0x8a5/0x1600 kernel/workqueue.c:2251
     #2: ffffffff8bf795c0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1da/0x3130 net/core/dev.c:4180
    
    stack backtrace:
    CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.13.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events ipvlan_process_multicast
    Call Trace:
     __dump_stack lib/dump_stack.c:79 [inline]
     dump_stack+0x141/0x1d7 lib/dump_stack.c:120
     __in6_dev_get include/net/addrconf.h:313 [inline]
     __in6_dev_get include/net/addrconf.h:311 [inline]
     neigh_reduce drivers/net/vxlan.c:2167 [inline]
     vxlan_xmit+0x34d5/0x4c30 drivers/net/vxlan.c:2919
     __netdev_start_xmit include/linux/netdevice.h:4944 [inline]
     netdev_start_xmit include/linux/netdevice.h:4958 [inline]
     xmit_one net/core/dev.c:3654 [inline]
     dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3670
     __dev_queue_xmit+0x2133/0x3130 net/core/dev.c:4246
     ipvlan_process_multicast+0xa99/0xd70 drivers/net/ipvlan/ipvlan_core.c:287
     process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
     worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
     kthread+0x3b1/0x4a0 kernel/kthread.c:313
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
    
    Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support")
    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: Sasha Levin <sashal@kernel.org>

commit 98fd088c325429327fc5ddb0b12c6a203ebf7f30
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jun 21 10:54:49 2021 -0700

    pkt_sched: sch_qfq: fix qfq_change_class() error path
    
    [ Upstream commit 0cd58e5c53babb9237b741dbef711f0a9eb6d3fd ]
    
    If qfq_change_class() is unable to allocate memory for qfq_aggregate,
    it frees the class that has been inserted in the class hash table,
    but does not unhash it.
    
    Defer the insertion after the problematic allocation.
    
    BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:884 [inline]
    BUG: KASAN: use-after-free in qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
    Write of size 8 at addr ffff88814a534f10 by task syz-executor.4/31478
    
    CPU: 0 PID: 31478 Comm: syz-executor.4 Not tainted 5.13.0-rc6-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:79 [inline]
     dump_stack+0x141/0x1d7 lib/dump_stack.c:120
     print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:233
     __kasan_report mm/kasan/report.c:419 [inline]
     kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436
     hlist_add_head include/linux/list.h:884 [inline]
     qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731
     qfq_change_class+0x96c/0x1990 net/sched/sch_qfq.c:489
     tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
     rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
     netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
     netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
     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+0x3a/0xb0 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x4665d9
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fdc7b5f0188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 00000000004665d9
    RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003
    RBP: 00007fdc7b5f01d0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
    R13: 00007ffcf7310b3f R14: 00007fdc7b5f0300 R15: 0000000000022000
    
    Allocated by task 31445:
     kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
     kasan_set_track mm/kasan/common.c:46 [inline]
     set_alloc_info mm/kasan/common.c:428 [inline]
     ____kasan_kmalloc mm/kasan/common.c:507 [inline]
     ____kasan_kmalloc mm/kasan/common.c:466 [inline]
     __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:516
     kmalloc include/linux/slab.h:556 [inline]
     kzalloc include/linux/slab.h:686 [inline]
     qfq_change_class+0x705/0x1990 net/sched/sch_qfq.c:464
     tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
     rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
     netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
     netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
     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+0x3a/0xb0 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Freed by task 31445:
     kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
     kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
     kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
     ____kasan_slab_free mm/kasan/common.c:360 [inline]
     ____kasan_slab_free mm/kasan/common.c:325 [inline]
     __kasan_slab_free+0xfb/0x130 mm/kasan/common.c:368
     kasan_slab_free include/linux/kasan.h:212 [inline]
     slab_free_hook mm/slub.c:1583 [inline]
     slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1608
     slab_free mm/slub.c:3168 [inline]
     kfree+0xe5/0x7f0 mm/slub.c:4212
     qfq_change_class+0x10fb/0x1990 net/sched/sch_qfq.c:518
     tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113
     rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564
     netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
     netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
     netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
     netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1929
     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+0x3a/0xb0 arch/x86/entry/common.c:47
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    The buggy address belongs to the object at ffff88814a534f00
     which belongs to the cache kmalloc-128 of size 128
    The buggy address is located 16 bytes inside of
     128-byte region [ffff88814a534f00, ffff88814a534f80)
    The buggy address belongs to the page:
    page:ffffea0005294d00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a534
    flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff)
    raw: 057ff00000000200 ffffea00004fee00 0000000600000006 ffff8880110418c0
    raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 29797, ts 604817765317, free_ts 604810151744
     prep_new_page mm/page_alloc.c:2358 [inline]
     get_page_from_freelist+0x1033/0x2b60 mm/page_alloc.c:3994
     __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5200
     alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2272
     alloc_slab_page mm/slub.c:1646 [inline]
     allocate_slab+0x2c5/0x4c0 mm/slub.c:1786
     new_slab mm/slub.c:1849 [inline]
     new_slab_objects mm/slub.c:2595 [inline]
     ___slab_alloc+0x4a1/0x810 mm/slub.c:2758
     __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2798
     slab_alloc_node mm/slub.c:2880 [inline]
     slab_alloc mm/slub.c:2922 [inline]
     __kmalloc+0x315/0x330 mm/slub.c:4050
     kmalloc include/linux/slab.h:561 [inline]
     kzalloc include/linux/slab.h:686 [inline]
     __register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1318
     mpls_dev_sysctl_register+0x1b7/0x2d0 net/mpls/af_mpls.c:1421
     mpls_add_dev net/mpls/af_mpls.c:1472 [inline]
     mpls_dev_notify+0x214/0x8b0 net/mpls/af_mpls.c:1588
     notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
     call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2121
     call_netdevice_notifiers_extack net/core/dev.c:2133 [inline]
     call_netdevice_notifiers net/core/dev.c:2147 [inline]
     register_netdevice+0x106b/0x1500 net/core/dev.c:10312
     veth_newlink+0x585/0xac0 drivers/net/veth.c:1547
     __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452
     rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500
    page last free stack trace:
     reset_page_owner include/linux/page_owner.h:24 [inline]
     free_pages_prepare mm/page_alloc.c:1298 [inline]
     free_pcp_prepare+0x223/0x300 mm/page_alloc.c:1342
     free_unref_page_prepare mm/page_alloc.c:3250 [inline]
     free_unref_page+0x12/0x1d0 mm/page_alloc.c:3298
     __vunmap+0x783/0xb60 mm/vmalloc.c:2566
     free_work+0x58/0x70 mm/vmalloc.c:80
     process_one_work+0x98d/0x1600 kernel/workqueue.c:2276
     worker_thread+0x64c/0x1120 kernel/workqueue.c:2422
     kthread+0x3b1/0x4a0 kernel/kthread.c:313
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
    
    Memory state around the buggy address:
     ffff88814a534e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88814a534e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    >ffff88814a534f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                             ^
     ffff88814a534f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88814a535000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    
    Fixes: 462dbc9101acd ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
    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: Sasha Levin <sashal@kernel.org>

commit fb9107d4fa7dddc351bd6ce77fefacd360ad1f66
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Jun 18 19:14:47 2021 +0300

    net: ethernet: ezchip: fix error handling
    
    [ Upstream commit 0de449d599594f5472e00267d651615c7f2c6c1d ]
    
    As documented at drivers/base/platform.c for platform_get_irq:
    
     * Gets an IRQ for a platform device and prints an error message if finding the
     * IRQ fails. Device drivers should check the return value for errors so as to
     * not pass a negative integer value to the request_irq() APIs.
    
    So, the driver should check that platform_get_irq() return value
    is _negative_, not that it's equal to zero, because -ENXIO (return
    value from request_irq() if irq was not found) will
    pass this check and it leads to passing negative irq to request_irq()
    
    Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e85822aada6f2cf80397c48ef31ab2c856724ac3
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Jun 18 19:14:31 2021 +0300

    net: ethernet: ezchip: fix UAF in nps_enet_remove
    
    [ Upstream commit e4b8700e07a86e8eab6916aa5c5ba99042c34089 ]
    
    priv is netdev private data, but it is used
    after free_netdev(). It can cause use-after-free when accessing priv
    pointer. So, fix it by moving free_netdev() after netif_napi_del()
    call.
    
    Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c8212ca64ef9df4c1c29552b3667d32f4754f6f7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri Jun 18 17:57:31 2021 +0300

    net: ethernet: aeroflex: fix UAF in greth_of_remove
    
    [ Upstream commit e3a5de6d81d8b2199935c7eb3f7d17a50a7075b7 ]
    
    static int greth_of_remove(struct platform_device *of_dev)
    {
    ...
            struct greth_private *greth = netdev_priv(ndev);
    ...
            unregister_netdev(ndev);
            free_netdev(ndev);
    
            of_iounmap(&of_dev->resource[0], greth->regs, resource_size(&of_dev->resource[0]));
    ...
    }
    
    greth is netdev private data, but it is used
    after free_netdev(). It can cause use-after-free when accessing greth
    pointer. So, fix it by moving free_netdev() after of_iounmap()
    call.
    
    Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver")
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b86fdd413e4296e1e3b282b405e32d2da8f1ea23
Author: Wang Hai <wanghai38@huawei.com>
Date:   Wed Jun 16 12:25:34 2021 +0800

    samples/bpf: Fix the error return code of xdp_redirect's main()
    
    [ Upstream commit 7c6090ee2a7b3315410cfc83a94c3eb057407b25 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    If bpf_map_update_elem() failed, main() should return a negative error.
    
    Fixes: 832622e6bd18 ("xdp: sample program for new bpf_redirect helper")
    Signed-off-by: Wang Hai <wanghai38@huawei.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/bpf/20210616042534.315097-1-wanghai38@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1853dabfd1516682192cd40595feaa86e69a3bba
Author: Bob Pearson <rpearsonhpe@gmail.com>
Date:   Fri Jun 4 18:05:59 2021 -0500

    RDMA/rxe: Fix qp reference counting for atomic ops
    
    [ Upstream commit 15ae1375ea91ae2dee6f12d71a79d8c0a10a30bf ]
    
    Currently the rdma_rxe driver attempts to protect atomic responder
    resources by taking a reference to the qp which is only freed when the
    resource is recycled for a new read or atomic operation. This means that
    in normal circumstances there is almost always an extra qp reference once
    an atomic operation has been executed which prevents cleaning up the qp
    and associated pd and cqs when the qp is destroyed.
    
    This patch removes the call to rxe_add_ref() in send_atomic_ack() and the
    call to rxe_drop_ref() in free_rd_atomic_resource(). If the qp is
    destroyed while a peer is retrying an atomic op it will cause the
    operation to fail which is acceptable.
    
    Link: https://lore.kernel.org/r/20210604230558.4812-1-rpearsonhpe@gmail.com
    Reported-by: Zhu Yanjun <zyjzyj2000@gmail.com>
    Fixes: 86af61764151 ("IB/rxe: remove unnecessary skb_clone")
    Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b97694d0a76c7b5f5e374dab2a3b1ef54899dc7
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Jun 11 19:26:56 2021 +0200

    netfilter: nft_tproxy: restrict support to TCP and UDP transport protocols
    
    [ Upstream commit 52f0f4e178c757b3d356087376aad8bd77271828 ]
    
    Add unfront check for TCP and UDP packets before performing further
    processing.
    
    Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3225cd78880a15928f8930e3de698a6edca63f42
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jun 10 20:20:31 2021 +0200

    netfilter: nft_osf: check for TCP packet before further processing
    
    [ Upstream commit 8f518d43f89ae00b9cf5460e10b91694944ca1a8 ]
    
    The osf expression only supports for TCP packets, add a upfront sanity
    check to skip packet parsing if this is not a TCP packet.
    
    Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0cb785dd9e42be71ec92fee8ef984c0a1e64dab3
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Jun 10 20:20:30 2021 +0200

    netfilter: nft_exthdr: check for IPv6 packet before further processing
    
    [ Upstream commit cdd73cc545c0fb9b1a1f7b209f4f536e7990cff4 ]
    
    ipv6_find_hdr() does not validate that this is an IPv6 packet. Add a
    sanity check for calling ipv6_find_hdr() to make sure an IPv6 packet
    is passed for parsing.
    
    Fixes: 96518518cc41 ("netfilter: add nftables")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c9629af44238a87f1283fbe20b671f741c17c55
Author: Leon Romanovsky <leon@kernel.org>
Date:   Mon May 31 19:04:44 2021 +0300

    RDMA/mlx5: Don't add slave port to unaffiliated list
    
    [ Upstream commit 7ce6095e3bff8e20ce018b050960b527e298f7df ]
    
    The mlx5_ib_bind_slave_port() doesn't remove multiport device from the
    unaffiliated list, but mlx5_ib_unbind_slave_port() did it. This unbalanced
    flow caused to the situation where mlx5_ib_unaffiliated_port_list was
    changed during iteration.
    
    Fixes: 32f69e4be269 ("{net, IB}/mlx5: Manage port association for multiport RoCE")
    Link: https://lore.kernel.org/r/2726e6603b1e6ecfe76aa5a12a063af72173bcf7.1622477058.git.leonro@nvidia.com
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0b6201184892db5c055ae6a02069460b61c3b62a
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Tue Jun 15 10:14:44 2021 +0800

    netlabel: Fix memory leak in netlbl_mgmt_add_common
    
    [ Upstream commit b8f6b0522c298ae9267bd6584e19b942a0636910 ]
    
    Hulk Robot reported memory leak in netlbl_mgmt_add_common.
    The problem is non-freed map in case of netlbl_domhsh_add() failed.
    
    BUG: memory leak
    unreferenced object 0xffff888100ab7080 (size 96):
      comm "syz-executor537", pid 360, jiffies 4294862456 (age 22.678s)
      hex dump (first 32 bytes):
        05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................
      backtrace:
        [<0000000008b40026>] netlbl_mgmt_add_common.isra.0+0xb2a/0x1b40
        [<000000003be10950>] netlbl_mgmt_add+0x271/0x3c0
        [<00000000c70487ed>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320
        [<000000001f2ff614>] genl_rcv_msg+0x2bf/0x4f0
        [<0000000089045792>] netlink_rcv_skb+0x134/0x3d0
        [<0000000020e96fdd>] genl_rcv+0x24/0x40
        [<0000000042810c66>] netlink_unicast+0x4a0/0x6a0
        [<000000002e1659f0>] netlink_sendmsg+0x789/0xc70
        [<000000006e43415f>] sock_sendmsg+0x139/0x170
        [<00000000680a73d7>] ____sys_sendmsg+0x658/0x7d0
        [<0000000065cbb8af>] ___sys_sendmsg+0xf8/0x170
        [<0000000019932b6c>] __sys_sendmsg+0xd3/0x190
        [<00000000643ac172>] do_syscall_64+0x37/0x90
        [<000000009b79d6dc>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Fixes: 63c416887437 ("netlabel: Add network address selectors to the NetLabel/LSM domain mapping")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5fbf4772fce975c381294a519a7d65b4df174e28
Author: Yang Li <yang.lee@linux.alibaba.com>
Date:   Tue May 25 18:46:17 2021 +0800

    ath10k: Fix an error code in ath10k_add_interface()
    
    [ Upstream commit e9ca70c735ce66fc6a0e02c8b6958434f74ef8de ]
    
    When the code execute this if statement, the value of ret is 0.
    However, we can see from the ath10k_warn() log that the value of
    ret should be -EINVAL.
    
    Clean up smatch warning:
    
    drivers/net/wireless/ath/ath10k/mac.c:5596 ath10k_add_interface() warn:
    missing error code 'ret'
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Fixes: ccec9038c721 ("ath10k: enable raw encap mode and software crypto engine")
    Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1621939577-62218-1-git-send-email-yang.lee@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 50ada21768e26c5de136e84457bf893953a1dd97
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed May 12 22:58:30 2021 +0200

    brcmsmac: mac80211_if: Fix a resource leak in an error handling path
    
    [ Upstream commit 9a25344d5177c2b9285532236dc3d10a091f39a8 ]
    
    If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()'
    as already done in the remove function.
    
    Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb33ddef99caa291283cf51b6bc917013da3c6f6
Author: Alvin Å ipraga <ALSI@bang-olufsen.dk>
Date:   Thu May 6 13:20:12 2021 +0000

    brcmfmac: correctly report average RSSI in station info
    
    [ Upstream commit 9a1590934d9a02e570636432b93052c0c035f31f ]
    
    The rx_lastpkt_rssi field provided by the firmware is suitable for
    NL80211_STA_INFO_{SIGNAL,CHAIN_SIGNAL}, while the rssi field is an
    average. Fix up the assignments and set the correct STA_INFO bits. This
    lets userspace know that the average RSSI is part of the station info.
    
    Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.")
    Signed-off-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210506132010.3964484-2-alsi@bang-olufsen.dk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f5c8dbcb2a08aa2ccf7c94e26e2aa67ac0a4f399
Author: Alvin Å ipraga <ALSI@bang-olufsen.dk>
Date:   Thu May 6 13:20:12 2021 +0000

    brcmfmac: fix setting of station info chains bitmask
    
    [ Upstream commit feb45643762172110cb3a44f99dd54304f33b711 ]
    
    The sinfo->chains field is a bitmask for filled values in chain_signal
    and chain_signal_avg, not a count. Treat it as such so that the driver
    can properly report per-chain RSSI information.
    
    Before (MIMO mode):
    
      $ iw dev wlan0 station dump
          ...
          signal: -51 [-51] dBm
    
    After (MIMO mode):
    
      $ iw dev wlan0 station dump
          ...
          signal: -53 [-53, -54] dBm
    
    Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.")
    Signed-off-by: Alvin Å ipraga <alsi@bang-olufsen.dk>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210506132010.3964484-1-alsi@bang-olufsen.dk
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a05091c9b2ef89c7d8c891dd420bd133fcd29176
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 15:29:49 2021 +0800

    ssb: Fix error return code in ssb_bus_scan()
    
    [ Upstream commit 77a0989baa427dbd242c5784d05a53ca3d197d43 ]
    
    Fix to return -EINVAL from the error handling case instead of 0, as done
    elsewhere in this function.
    
    Fixes: 61e115a56d1a ("[SSB]: add Sonics Silicon Backplane bus support")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Acked-by: Michael Büsch <m@bues.ch>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210515072949.7151-1-thunder.leizhen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0418cb6b7fe3eb1bd18e9eda5e1f401e8faad838
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Sat Jun 5 18:33:47 2021 +0100

    wcn36xx: Move hal_buf allocation to devm_kmalloc in probe
    
    [ Upstream commit ef48667557c53d4b51a1ee3090eab7699324c9de ]
    
    Right now wcn->hal_buf is allocated in wcn36xx_start(). This is a problem
    since we should have setup all of the buffers we required by the time
    ieee80211_register_hw() is called.
    
    struct ieee80211_ops callbacks may run prior to mac_start() and therefore
    wcn->hal_buf must be initialized.
    
    This is easily remediated by moving the allocation to probe() taking the
    opportunity to tidy up freeing memory by using devm_kmalloc().
    
    Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210605173347.2266003-1-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 82edefd4a3cc3abddfb63cbe55df23eeb2291245
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Fri Jun 11 09:58:12 2021 +0800

    ieee802154: hwsim: Fix possible memory leak in hwsim_subscribe_all_others
    
    [ Upstream commit ab372c2293f5d0b279f31c8d768566ea37602dc9 ]
    
    In hwsim_subscribe_all_others, the error handling code performs
    incorrectly if the second hwsim_alloc_edge fails. When this issue occurs,
    it goes to sub_fail, without cleaning the edges allocated before.
    
    Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb")
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Link: https://lore.kernel.org/r/20210611015812.1626999-1-mudongliangabcd@gmail.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c957e3244fabdbfe3fbdd4e083f993d4dc7fcea1
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon May 31 17:41:28 2021 +0300

    wireless: carl9170: fix LEDS build errors & warnings
    
    [ Upstream commit 272fdc0c4542fad173b44965be02a16d6db95499 ]
    
    kernel test robot reports over 200 build errors and warnings
    that are due to this Kconfig problem when CARL9170=m,
    MAC80211=y, and LEDS_CLASS=m.
    
    WARNING: unmet direct dependencies detected for MAC80211_LEDS
      Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
      Selected by [m]:
      - CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m]
    
    CARL9170_LEDS selects MAC80211_LEDS even though its kconfig
    dependencies are not met. This happens because 'select' does not follow
    any Kconfig dependency chains.
    
    Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where
    the latter supplies any needed dependencies on LEDS_CLASS.
    
    Fixes: 1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: Christian Lamparter <chunkeey@googlemail.com>
    Cc: linux-wireless@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Suggested-by: Christian Lamparter <chunkeey@googlemail.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Christian Lamparter <chunkeey@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 80680f3b1316fa4a39328b04756ea76e4ca8c389
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Wed Jun 9 19:59:16 2021 +0800

    tools/bpftool: Fix error return code in do_batch()
    
    [ Upstream commit ca16b429f39b4ce013bfa7e197f25681e65a2a42 ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 668da745af3c2 ("tools: bpftool: add support for quotations ...")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Reviewed-by: Quentin Monnet <quentin@isovalent.com>
    Link: https://lore.kernel.org/bpf/20210609115916.2186872-1-chengzhihao1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8dc74a8bbc05b3a1ee2765b547d9ca5d39cae687
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jun 8 17:13:13 2021 +0100

    drm: qxl: ensure surf.data is ininitialized
    
    [ Upstream commit fbbf23ddb2a1cc0c12c9f78237d1561c24006f50 ]
    
    The object surf is not fully initialized and the uninitialized
    field surf.data is being copied by the call to qxl_bo_create
    via the call to qxl_gem_object_create. Set surf.data to zero
    to ensure garbage data from the stack is not being copied.
    
    Addresses-Coverity: ("Uninitialized scalar variable")
    Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20210608161313.161922-1-colin.king@canonical.com
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c92357b336e3f1344e0230f08a50a6112331161c
Author: Kamal Heib <kamalheib1@gmail.com>
Date:   Thu Jun 3 12:01:12 2021 +0300

    RDMA/rxe: Fix failure during driver load
    
    [ Upstream commit 32a25f2ea690dfaace19f7a3a916f5d7e1ddafe8 ]
    
    To avoid the following failure when trying to load the rdma_rxe module
    while IPv6 is disabled, add a check for EAFNOSUPPORT and ignore the
    failure, also delete the needless debug print from rxe_setup_udp_tunnel().
    
    $ modprobe rdma_rxe
    modprobe: ERROR: could not insert 'rdma_rxe': Operation not permitted
    
    Fixes: dfdd6158ca2c ("IB/rxe: Fix kernel panic in udp_setup_tunnel")
    Link: https://lore.kernel.org/r/20210603090112.36341-1-kamalheib1@gmail.com
    Reported-by: Yi Zhang <yi.zhang@redhat.com>
    Signed-off-by: Kamal Heib <kamalheib1@gmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 22d663bf6fcc43f67acead300884f1d98332822f
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Fri May 28 16:55:55 2021 +0800

    ehea: fix error return code in ehea_restart_qps()
    
    [ Upstream commit 015dbf5662fd689d581c0bc980711b073ca09a1a ]
    
    Fix to return -EFAULT from the error handling case instead of 0, as done
    elsewhere in this function.
    
    By the way, when get_zeroed_page() fails, directly return -ENOMEM to
    simplify code.
    
    Fixes: 2c69448bbced ("ehea: DLPAR memory add fix")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210528085555.9390-1-thunder.leizhen@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0715ea013f6e7beb183535933ee9fbbb051285e0
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed May 19 21:49:28 2021 +0800

    drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write()
    
    [ Upstream commit ae41d925c75b53798f289c69ee8d9f7d36432f6d ]
    
    After calling clk_prepare_enable(), clk_disable_unprepare() need
    be called when calling regmap_write() failed.
    
    Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210519134928.2696617-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4de95ea6e064f0e519e4899d14705406e105f1bd
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon May 10 19:39:27 2021 +0300

    net: pch_gbe: Propagate error from devm_gpio_request_one()
    
    [ Upstream commit 9e3617a7b84512bf96c04f9cf82d1a7257d33794 ]
    
    If GPIO controller is not available yet we need to defer
    the probe of GBE until provider will become available.
    
    While here, drop GPIOF_EXPORT because it's deprecated and
    may not be available.
    
    Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Tested-by: Flavio Suligoi <f.suligoi@asem.it>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b4bbd7605fe1e7aa47de7ee6619ae5c84e653adc
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Mon May 10 12:58:05 2021 +0300

    net: mvpp2: Put fwnode in error case during ->probe()
    
    [ Upstream commit 71f0891c84dfdc448736082ab0a00acd29853896 ]
    
    In each iteration fwnode_for_each_available_child_node() bumps a reference
    counting of a loop variable followed by dropping in on a next iteration,
    
    Since in error case the loop is broken, we have to drop a reference count
    by ourselves. Do it for port_fwnode in error case during ->probe().
    
    Fixes: 248122212f68 ("net: mvpp2: use device_*/fwnode_* APIs instead of of_*")
    Cc: Marcin Wojtas <mw@semihalf.com>
    Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bbf4fff7b4e35472ca324ad6f57baf08b03aec63
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Mon Jun 28 19:34:01 2021 -0700

    ocfs2: fix snprintf() checking
    
    [ Upstream commit 54e948c60cc843b6e84dc44496edc91f51d2a28e ]
    
    The snprintf() function returns the number of bytes which would have been
    printed if the buffer was large enough.  In other words it can return ">=
    remain" but this code assumes it returns "== remain".
    
    The run time impact of this bug is not very severe.  The next iteration
    through the loop would trigger a WARN() when we pass a negative limit to
    snprintf().  We would then return success instead of -E2BIG.
    
    The kernel implementation of snprintf() will never return negatives so
    there is no need to check and I have deleted that dead code.
    
    Link: https://lkml.kernel.org/r/20210511135350.GV1955@kadam
    Fixes: a860f6eb4c6a ("ocfs2: sysfile interfaces for online file check")
    Fixes: 74ae4e104dfc ("ocfs2: Create stack glue sysfs files.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 30cfe6a081b701c34a7427e9044f0d62c2bd08a9
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat Jun 19 17:37:00 2021 +0800

    blk-wbt: make sure throttle is enabled properly
    
    [ Upstream commit 76a8040817b4b9c69b53f9b326987fa891b4082a ]
    
    After commit a79050434b45 ("blk-rq-qos: refactor out common elements of
    blk-wbt"), if throttle was disabled by wbt_disable_default(), we could
    not enable again, fix this by set enable_state back to
    WBT_STATE_ON_DEFAULT.
    
    Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt")
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Link: https://lore.kernel.org/r/20210619093700.920393-3-yi.zhang@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 327e0b2c0c4281cb9bc1c5814e4e999d0af1b1c7
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat Jun 19 17:36:59 2021 +0800

    blk-wbt: introduce a new disable state to prevent false positive by rwb_enabled()
    
    [ Upstream commit 1d0903d61e9645c6330b94247b96dd873dfc11c8 ]
    
    Now that we disable wbt by simply zero out rwb->wb_normal in
    wbt_disable_default() when switch elevator to bfq, but it's not safe
    because it will become false positive if we change queue depth. If it
    become false positive between wbt_wait() and wbt_track() when submit
    write request, it will lead to drop rqw->inflight to -1 in wbt_done(),
    which will end up trigger IO hung. Fix this issue by introduce a new
    state which mean the wbt was disabled.
    
    Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt")
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Link: https://lore.kernel.org/r/20210619093700.920393-2-yi.zhang@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 32afb981e38c0f68185eac93a673d9d9a7e260ca
Author: Krzysztof Wilczyński <kw@linux.com>
Date:   Thu Jun 3 17:12:01 2021 +0000

    ACPI: sysfs: Fix a buffer overrun problem with description_show()
    
    [ Upstream commit 888be6067b97132c3992866bbcf647572253ab3f ]
    
    Currently, a device description can be obtained using ACPI, if the _STR
    method exists for a particular device, and then exposed to the userspace
    via a sysfs object as a string value.
    
    If the _STR method is available for a given device then the data
    (usually a Unicode string) is read and stored in a buffer (of the
    ACPI_TYPE_BUFFER type) with a pointer to said buffer cached in the
    struct acpi_device_pnp for later access.
    
    The description_show() function is responsible for exposing the device
    description to the userspace via a corresponding sysfs object and
    internally calls the utf16s_to_utf8s() function with a pointer to the
    buffer that contains the Unicode string so that it can be converted from
    UTF16 encoding to UTF8 and thus allowing for the value to be safely
    stored and later displayed.
    
    When invoking the utf16s_to_utf8s() function, the description_show()
    function also sets a limit of the data that can be saved into a provided
    buffer as a result of the character conversion to be a total of
    PAGE_SIZE, and upon completion, the utf16s_to_utf8s() function returns
    an integer value denoting the number of bytes that have been written
    into the provided buffer.
    
    Following the execution of the utf16s_to_utf8s() a newline character
    will be added at the end of the resulting buffer so that when the value
    is read in the userspace through the sysfs object then it would include
    newline making it more accessible when working with the sysfs file
    system in the shell, etc.  Normally, this wouldn't be a problem, but if
    the function utf16s_to_utf8s() happens to return the number of bytes
    written to be precisely PAGE_SIZE, then we would overrun the buffer and
    write the newline character outside the allotted space which can have
    undefined consequences or result in a failure.
    
    To fix this buffer overrun, ensure that there always is enough space
    left for the newline character to be safely appended.
    
    Fixes: d1efe3c324ea ("ACPI: Add new sysfs interface to export device description")
    Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
    Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f85e7b202aa2e664ce6f58ad5817f8cc39ae8eeb
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Jun 17 15:57:12 2021 +0800

    crypto: nx - Fix RCU warning in nx842_OF_upd_status
    
    [ Upstream commit 2a96726bd0ccde4f12b9b9a9f61f7b1ac5af7e10 ]
    
    The function nx842_OF_upd_status triggers a sparse RCU warning when
    it directly dereferences the RCU-protected devdata.  This appears
    to be an accident as there was another variable of the same name
    that was passed in from the caller.
    
    After it was removed (because the main purpose of using it, to
    update the status member was itself removed) the global variable
    unintenionally stood in as its replacement.
    
    This patch restores the devdata parameter.
    
    Fixes: 90fd73f912f0 ("crypto: nx - remove pSeries NX 'status' field")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ed556eef5fedd69219dfa8e0e3864347eff8e76e
Author: Mirko Vogt <mirko-dev|linux@nanl.de>
Date:   Mon Jun 14 16:45:07 2021 +0200

    spi: spi-sun6i: Fix chipselect/clock bug
    
    [ Upstream commit 0d7993b234c9fad8cb6bec6adfaa74694ba85ecb ]
    
    The current sun6i SPI implementation initializes the transfer too early,
    resulting in SCK going high before the transfer. When using an additional
    (gpio) chipselect with sun6i, the chipselect is asserted at a time when
    clock is high, making the SPI transfer fail.
    
    This is due to SUN6I_GBL_CTL_BUS_ENABLE being written into
    SUN6I_GBL_CTL_REG at an early stage. Moving that to the transfer
    function, hence, right before the transfer starts, mitigates that
    problem.
    
    Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
    Signed-off-by: Mirko Vogt <mirko-dev|linux@nanl.de>
    Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com>
    Link: https://lore.kernel.org/r/20210614144507.y3udezjfbko7eavv@runtux.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ea61234a1c593b2542fdd829212109f5067032e0
Author: David Sterba <dsterba@suse.com>
Date:   Tue Jul 7 18:38:05 2020 +0200

    btrfs: clear log tree recovering status if starting transaction fails
    
    [ Upstream commit 1aeb6b563aea18cd55c73cf666d1d3245a00f08c ]
    
    When a log recovery is in progress, lots of operations have to take that
    into account, so we keep this status per tree during the operation. Long
    time ago error handling revamp patch 79787eaab461 ("btrfs: replace many
    BUG_ONs with proper error handling") removed clearing of the status in
    an error branch. Add it back as was intended in e02119d5a7b4 ("Btrfs:
    Add a write ahead tree log to optimize synchronous operations").
    
    There are probably no visible effects, log replay is done only during
    mount and if it fails all structures are cleared so the stale status
    won't be kept.
    
    Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling")
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96d87260d3e1878c3d48f57d84493d3c1a9f7b89
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Wed May 26 08:40:16 2021 -0700

    hwmon: (max31790) Fix fan speed reporting for fan7..12
    
    [ Upstream commit cbbf244f0515af3472084f22b6213121b4a63835 ]
    
    Fans 7..12 do not have their own set of configuration registers.
    So far the code ignored that and read beyond the end of the configuration
    register range to get the tachometer period. This resulted in more or less
    random fan speed values for those fans.
    
    The datasheet is quite vague when it comes to defining the tachometer
    period for fans 7..12. Experiments confirm that the period is the same
    for both fans associated with a given set of configuration registers.
    
    Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API")
    Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790")
    Cc: Jan Kundrát <jan.kundrat@cesnet.cz>
    Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Cc: Václav Kubernát <kubernat@cesnet.cz>
    Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18604ddea7fb510930c78685c5dec7a16f6c8e70
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat May 8 09:50:25 2021 -0700

    hwmon: (max31722) Remove non-standard ACPI device IDs
    
    [ Upstream commit 97387c2f06bcfd79d04a848d35517b32ee6dca7c ]
    
    Valid Maxim Integrated ACPI device IDs would start with MXIM,
    not with MAX1. On top of that, ACPI device IDs reflecting chip names
    are almost always invalid.
    
    Remove the invalid ACPI IDs.
    
    Fixes: 04e1e70afec6 ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4980ea4797249b179a2732170e58f579d08fa5b2
Author: Dillon Min <dillon.minfei@gmail.com>
Date:   Wed May 26 17:18:32 2021 +0200

    media: s5p-g2d: Fix a memory leak on ctx->fh.m2m_ctx
    
    [ Upstream commit 5d11e6aad1811ea293ee2996cec9124f7fccb661 ]
    
    The m2m_ctx resources was allocated by v4l2_m2m_ctx_init() in g2d_open()
    should be freed from g2d_release() when it's not used.
    
    Fix it
    
    Fixes: 918847341af0 ("[media] v4l: add G2D driver for s5p device family")
    Signed-off-by: Dillon Min <dillon.minfei@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 841664338b920641a9289b75264a7f87f391baeb
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 10:03:21 2021 +0800

    mmc: usdhi6rol0: fix error return code in usdhi6_probe()
    
    [ Upstream commit 2f9ae69e5267f53e89e296fccee291975a85f0eb ]
    
    Fix to return a negative error code from the error handling case instead
    of 0, as done elsewhere in this function.
    
    Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Link: https://lore.kernel.org/r/20210508020321.1677-1-thunder.leizhen@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 278d1d2cfd56598a15c48356bfca28c1b5f421ba
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Wed Mar 10 19:40:43 2021 -0600

    media: siano: Fix out-of-bounds warnings in smscore_load_firmware_family2()
    
    [ Upstream commit 13dfead49db07225335d4f587a560a2210391a1a ]
    
    Rename struct sms_msg_data4 to sms_msg_data5 and increase the size of
    its msg_data array from 4 to 5 elements. Notice that at some point
    the 5th element of msg_data is being accessed in function
    smscore_load_firmware_family2():
    
    1006                 trigger_msg->msg_data[4] = 4; /* Task ID */
    
    Also, there is no need for the object _trigger_msg_ of type struct
    sms_msg_data *, when _msg_ can be used, directly. Notice that msg_data
    in struct sms_msg_data is a one-element array, which causes multiple
    out-of-bounds warnings when accessing beyond its first element
    in function smscore_load_firmware_family2():
    
     992                 struct sms_msg_data *trigger_msg =
     993                         (struct sms_msg_data *) msg;
     994
     995                 pr_debug("sending MSG_SMS_SWDOWNLOAD_TRIGGER_REQ\n");
     996                 SMS_INIT_MSG(&msg->x_msg_header,
     997                                 MSG_SMS_SWDOWNLOAD_TRIGGER_REQ,
     998                                 sizeof(struct sms_msg_hdr) +
     999                                 sizeof(u32) * 5);
    1000
    1001                 trigger_msg->msg_data[0] = firmware->start_address;
    1002                                         /* Entry point */
    1003                 trigger_msg->msg_data[1] = 6; /* Priority */
    1004                 trigger_msg->msg_data[2] = 0x200; /* Stack size */
    1005                 trigger_msg->msg_data[3] = 0; /* Parameter */
    1006                 trigger_msg->msg_data[4] = 4; /* Task ID */
    
    even when enough dynamic memory is allocated for _msg_:
    
     929         /* PAGE_SIZE buffer shall be enough and dma aligned */
     930         msg = kmalloc(PAGE_SIZE, GFP_KERNEL | coredev->gfp_buf_flags);
    
    but as _msg_ is casted to (struct sms_msg_data *):
    
     992                 struct sms_msg_data *trigger_msg =
     993                         (struct sms_msg_data *) msg;
    
    the out-of-bounds warnings are actually valid and should be addressed.
    
    Fix this by declaring object _msg_ of type struct sms_msg_data5 *,
    which contains a 5-elements array, instead of just 4. And use
    _msg_ directly, instead of creating object trigger_msg.
    
    This helps with the ongoing efforts to enable -Warray-bounds by fixing
    the following warnings:
    
      CC [M]  drivers/media/common/siano/smscoreapi.o
    drivers/media/common/siano/smscoreapi.c: In function ‘smscore_load_firmware_family2’:
    drivers/media/common/siano/smscoreapi.c:1003:24: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
     1003 |   trigger_msg->msg_data[1] = 6; /* Priority */
          |   ~~~~~~~~~~~~~~~~~~~~~^~~
    In file included from drivers/media/common/siano/smscoreapi.c:12:
    drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
      619 |  u32 msg_data[1];
          |      ^~~~~~~~
    drivers/media/common/siano/smscoreapi.c:1004:24: warning: array subscript 2 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
     1004 |   trigger_msg->msg_data[2] = 0x200; /* Stack size */
          |   ~~~~~~~~~~~~~~~~~~~~~^~~
    In file included from drivers/media/common/siano/smscoreapi.c:12:
    drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
      619 |  u32 msg_data[1];
          |      ^~~~~~~~
    drivers/media/common/siano/smscoreapi.c:1005:24: warning: array subscript 3 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
     1005 |   trigger_msg->msg_data[3] = 0; /* Parameter */
          |   ~~~~~~~~~~~~~~~~~~~~~^~~
    In file included from drivers/media/common/siano/smscoreapi.c:12:
    drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
      619 |  u32 msg_data[1];
          |      ^~~~~~~~
    drivers/media/common/siano/smscoreapi.c:1006:24: warning: array subscript 4 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
     1006 |   trigger_msg->msg_data[4] = 4; /* Task ID */
          |   ~~~~~~~~~~~~~~~~~~~~~^~~
    In file included from drivers/media/common/siano/smscoreapi.c:12:
    drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’
      619 |  u32 msg_data[1];
          |      ^~~~~~~~
    
    Fixes: 018b0c6f8acb ("[media] siano: make load firmware logic to work with newer firmwares")
    Co-developed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ee59cafe5de910a429f44cc48b245847b6edd0fe
Author: Johan Hovold <johan@kernel.org>
Date:   Mon May 24 13:09:18 2021 +0200

    media: gspca/gl860: fix zero-length control requests
    
    [ Upstream commit 8ed339f23d41e21660a389adf2e7b2966d457ff6 ]
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Control transfers without a data stage are treated as OUT requests by
    the USB stack and should be using usb_sndctrlpipe(). Failing to do so
    will now trigger a warning.
    
    Fix the gl860_RTx() helper so that zero-length control reads fail with
    an error message instead. Note that there are no current callers that
    would trigger this.
    
    Fixes: 4f7cb8837cec ("V4L/DVB (12954): gspca - gl860: Addition of GL860 based webcams")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f8985454809f165a29961c434bb523bbf110acb3
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 15 08:58:30 2021 +0200

    media: tc358743: Fix error return code in tc358743_probe_of()
    
    [ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ]
    
    When the CSI bps per lane is not in the valid range, an appropriate error
    code -EINVAL should be returned. However, we currently do not explicitly
    assign this error code to 'ret'. As a result, 0 was incorrectly returned.
    
    Fixes: 256148246852 ("[media] tc358743: support probe from device tree")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b334329a212ffd9dee8429d2bef2fcfc8d701f9d
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Sun May 9 10:12:31 2021 +0200

    media: exynos4-is: Fix a use after free in isp_video_release
    
    [ Upstream commit 01fe904c9afd26e79c1f73aa0ca2e3d785e5e319 ]
    
    In isp_video_release, file->private_data is freed via
    _vb2_fop_release()->v4l2_fh_release(). But the freed
    file->private_data is still used in v4l2_fh_is_singular_file()
    ->v4l2_fh_is_singular(file->private_data), which is a use
    after free bug.
    
    My patch uses a variable 'is_singular_file' to avoid the uaf.
    v3: https://lore.kernel.org/patchwork/patch/1419058/
    
    Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 65bff47cd80db4260cda82673e907079600404da
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date:   Sat Mar 20 23:32:38 2021 +0300

    pata_ep93xx: fix deferred probing
    
    [ Upstream commit 5c8121262484d99bffb598f39a0df445cecd8efb ]
    
    The driver overrides the error codes returned by platform_get_irq() to
    -ENXIO, so if it returns -EPROBE_DEFER, the driver would fail the probe
    permanently instead of the deferred probing.  Propagate the error code
    upstream, as it should have been done from the start...
    
    Fixes: 2fff27512600 ("PATA host controller driver for ep93xx")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Link: https://lore.kernel.org/r/509fda88-2e0d-2cc7-f411-695d7e94b136@omprussia.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16c3ce907e9801dd2f2c35a56d924f679323be22
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Thu May 6 07:38:56 2021 +0200

    media: rc: i2c: Fix an error message
    
    [ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ]
    
    'ret' is known to be 1 here. In fact 'i' is expected instead.
    Store the return value of 'i2c_master_recv()' in 'ret' so that the error
    message print the correct error code.
    
    Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d6cd8cef18c0db5566728fbfe0ad2f7a5a204d58
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun May 16 08:58:04 2021 +0200

    crypto: ccp - Fix a resource leak in an error handling path
    
    [ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ]
    
    If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be
    called as already done in the error handling path.
    
    Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Acked-by: John Allen <john.allen@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8657d0d57d6df9d6d04277c18889da2804164ca3
Author: Mimi Zohar <zohar@linux.ibm.com>
Date:   Mon Apr 26 18:13:45 2021 -0400

    evm: fix writing <securityfs>/evm overflow
    
    [ Upstream commit 49219d9b8785ba712575c40e48ce0f7461254626 ]
    
    EVM_SETUP_COMPLETE is defined as 0x80000000, which is larger than INT_MAX.
    The "-fno-strict-overflow" compiler option properly prevents signaling
    EVM that the EVM policy setup is complete.  Define and read an unsigned
    int.
    
    Fixes: f00d79750712 ("EVM: Allow userspace to signal an RSA key has been loaded")
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7dbb2a67b9f8e5e508ee37acc1b86a233930526
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date:   Tue May 18 23:38:54 2021 +0300

    pata_octeon_cf: avoid WARN_ON() in ata_host_activate()
    
    [ Upstream commit bfc1f378c8953e68ccdbfe0a8c20748427488b80 ]
    
    Iff platform_get_irq() fails (or returns IRQ0) and thus the polling mode
    has to be used, ata_host_activate() hits the WARN_ON() due to 'irq_handler'
    parameter being non-NULL if the polling mode is selected.  Let's only set
    the pointer to the driver's IRQ handler if platform_get_irq() returns a
    valid IRQ # -- this should avoid the unnecessary WARN_ON()...
    
    Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/3a241167-f84d-1d25-5b9b-be910afbe666@omp.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 709d077bbcf4249f6c760355a676565f60de1d59
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Fri Apr 30 22:19:55 2021 +0200

    media: I2C: change 'RST' to "RSET" to fix multiple build errors
    
    [ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ]
    
    The use of an enum named 'RST' conflicts with a #define macro
    named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h.
    
    The MIPS use of RST was there first (AFAICT), so change the
    media/i2c/ uses of RST to be named 'RSET'.
    'git grep -w RSET' does not report any naming conflicts with the
    new name.
    
    This fixes multiple build errors:
    
    arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
       15 | #define RST  (1 << 15)
          |              ^
    drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST'
      356 |  RST,
          |  ^~~
    
    ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
       15 | #define RST  (1 << 15)
          |              ^
    ../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST'
      180 |  RST,
          |  ^~~
    
    ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token
       15 | #define RST  (1 << 15)
          |              ^
    ../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST'
      238 |  RST,
          |  ^~~
    
    and some others that I have trimmed.
    
    Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver")
    Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor")
    Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor")
    Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
    Cc: Andrzej Hajda <a.hajda@samsung.com>
    Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Cc: Sangwook Lee <sangwook.lee@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97c9919de33b7b100800a513016842720bbb2822
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date:   Mon Mar 15 14:46:53 2021 +0300

    pata_rb532_cf: fix deferred probing
    
    [ Upstream commit 2d3a62fbae8e5badc2342388f65ab2191c209cc0 ]
    
    The driver overrides the error codes returned by platform_get_irq() to
    -ENOENT, so if it returns -EPROBE_DEFER, the driver would fail the probe
    permanently instead of the deferred probing. Switch to propagating the
    error code upstream, still checking/overriding IRQ0 as libata regards it
    as "no IRQ" (thus polling) anyway...
    
    Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Link: https://lore.kernel.org/r/771ced55-3efb-21f5-f21c-b99920aae611@omprussia.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 48715b7f8560f6a5e3fff0c4f2b7c413ee999c15
Author: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Date:   Sun Mar 14 23:34:27 2021 +0300

    sata_highbank: fix deferred probing
    
    [ Upstream commit 4a24efa16e7db02306fb5db84518bb0a7ada5a46 ]
    
    The driver overrides the error codes returned by platform_get_irq() to
    -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe
    permanently instead of the deferred probing. Switch to propagating the
    error code upstream, still checking/overriding IRQ0 as libata regards it
    as "no IRQ" (thus polling) anyway...
    
    Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
    Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
    Link: https://lore.kernel.org/r/105b456d-1199-f6e9-ceb7-ffc5ba551d1a@omprussia.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0d574e45410b8769853e040ec1e3e6040ea39e71
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Sat May 8 15:00:49 2021 +0800

    crypto: ux500 - Fix error return code in hash_hw_final()
    
    [ Upstream commit b01360384009ab066940b45f34880991ea7ccbfb ]
    
    Fix to return a negative error code from the error handling
    case instead of 0, as done elsewhere in this function.
    
    Fixes: 8a63b1994c50 ("crypto: ux500 - Add driver for HASH hardware")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 70bc9a0178b346d331f97ac6694f672aaa8862a5
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Wed May 5 20:26:08 2021 +0000

    crypto: ixp4xx - dma_unmap the correct address
    
    [ Upstream commit 9395c58fdddd79cdd3882132cdd04e8ac7ad525f ]
    
    Testing ixp4xx_crypto with CONFIG_DMA_API_DEBUG lead to the following error:
    DMA-API: platform ixp4xx_crypto.0: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=24 bytes]
    
    This is due to dma_unmap using the wrong address.
    
    Fixes: 0d44dc59b2b4 ("crypto: ixp4xx - Fix handling of chained sg buffers")
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b29ef99d9e4a0ce7b25a5e67536cf191c6eabc34
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Wed Apr 28 09:38:56 2021 +0200

    media: s5p_cec: decrement usage count if disabled
    
    [ Upstream commit 747bad54a677d8633ec14b39dfbeb859c821d7f2 ]
    
    There's a bug at s5p_cec_adap_enable(): if called to
    disable the device, it should call pm_runtime_put()
    instead of pm_runtime_disable(), as the goal here is to
    decrement the usage_count and not to disable PM runtime.
    
    Reported-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Fixes: 1bcbf6f4b6b0 ("[media] cec: s5p-cec: Add s5p-cec driver")
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fd7b9a5a4b440df24d349128e5afcce7ca9c6f25
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jun 28 19:33:41 2021 -0700

    ia64: mca_drv: fix incorrect array size calculation
    
    [ Upstream commit c5f320ff8a79501bb59338278336ec43acb9d7e2 ]
    
    gcc points out a mistake in the mca driver that goes back to before the
    git history:
    
    arch/ia64/kernel/mca_drv.c: In function 'init_record_index_pools':
    arch/ia64/kernel/mca_drv.c:346:54: error: expression does not compute the number of elements in this array; element typ
    e is 'int', not 'size_t' {aka 'long unsigned int'} [-Werror=sizeof-array-div]
      346 |         for (i = 1; i < sizeof sal_log_sect_min_sizes/sizeof(size_t); i++)
          |                                                      ^
    
    This is the same as sizeof(size_t), which is two shorter than the actual
    array.  Use the ARRAY_SIZE() macro to get the correct calculation instead.
    
    Link: https://lkml.kernel.org/r/20210514214123.875971-1-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 075b291c5d2152af1557ca3fc9f8b3f144608249
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Wed Jun 23 09:58:09 2021 -0700

    HID: wacom: Correct base usage for capacitive ExpressKey status bits
    
    [ Upstream commit 424d8237945c6c448c8b3f23885d464fb5685c97 ]
    
    The capacitive status of ExpressKeys is reported with usages beginning
    at 0x940, not 0x950. Bring our driver into alignment with reality.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cdf94d8d75c4cd935a4ee37671241c7366045715
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Jun 21 16:24:33 2021 +0100

    ACPI: tables: Add custom DSDT file as makefile prerequisite
    
    [ Upstream commit d1059c1b1146870c52f3dac12cb7b6cbf39ed27f ]
    
    A custom DSDT file is mostly used during development or debugging,
    and in that case it is quite likely to want to rebuild the kernel
    after changing ONLY the content of the DSDT.
    
    This patch adds the custom DSDT as a prerequisite to tables.o
    to ensure a rebuild if the DSDT file is updated. Make will merge
    the prerequisites from multiple rules for the same target.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 73af8425a57f69d00b0954a15f099355bb9783d5
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Thu May 27 12:01:19 2021 -0700

    clocksource: Retry clock read if long delays detected
    
    [ Upstream commit db3a34e17433de2390eb80d436970edcebd0ca3e ]
    
    When the clocksource watchdog marks a clock as unstable, this might be due
    to that clock being unstable or it might be due to delays that happen to
    occur between the reads of the two clocks.  Yes, interrupts are disabled
    across those two reads, but there are no shortage of things that can delay
    interrupts-disabled regions of code ranging from SMI handlers to vCPU
    preemption.  It would be good to have some indication as to why the clock
    was marked unstable.
    
    Therefore, re-read the watchdog clock on either side of the read from the
    clock under test.  If the watchdog clock shows an excessive time delta
    between its pair of reads, the reads are retried.
    
    The maximum number of retries is specified by a new kernel boot parameter
    clocksource.max_cswd_read_retries, which defaults to three, that is, up to
    four reads, one initial and up to three retries.  If more than one retry
    was required, a message is printed on the console (the occasional single
    retry is expected behavior, especially in guest OSes).  If the maximum
    number of retries is exceeded, the clock under test will be marked
    unstable.  However, the probability of this happening due to various sorts
    of delays is quite small.  In addition, the reason (clock-read delays) for
    the unstable marking will be apparent.
    
    Reported-by: Chris Mason <clm@fb.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Feng Tang <feng.tang@intel.com>
    Link: https://lore.kernel.org/r/20210527190124.440372-1-paulmck@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e889b3d35541dd8f4926efa22b7f8cf16320fa2
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date:   Wed Jun 2 18:05:48 2021 +0800

    platform/x86: toshiba_acpi: Fix missing error code in toshiba_acpi_setup_keyboard()
    
    [ Upstream commit 28e367127718a9cb85d615a71e152f7acee41bfc ]
    
    The error code is missing in this code scenario, add the error code
    '-EINVAL' to the return value 'error'.
    
    Eliminate the follow smatch warning:
    
    drivers/platform/x86/toshiba_acpi.c:2834 toshiba_acpi_setup_keyboard()
    warn: missing error code 'error'.
    
    Reported-by: Abaci Robot <abaci@linux.alibaba.com>
    Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
    Link: https://lore.kernel.org/r/1622628348-87035-1-git-send-email-jiapeng.chong@linux.alibaba.com
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b020044bee32c599b3e25f0b110b6e25e7f789d7
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Wed Jun 2 17:36:50 2021 +0800

    ACPI: bus: Call kobject_put() in acpi_init() error path
    
    [ Upstream commit 4ac7a817f1992103d4e68e9837304f860b5e7300 ]
    
    Although the system will not be in a good condition or it will not
    boot if acpi_bus_init() fails, it is still necessary to put the
    kobject in the error path before returning to avoid leaking memory.
    
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc346f84e15189ab3b0453d8aad8471fdb9ad28e
Author: Erik Kaneda <erik.kaneda@intel.com>
Date:   Fri Jun 4 14:25:57 2021 -0700

    ACPICA: Fix memory leak caused by _CID repair function
    
    [ Upstream commit c27bac0314131b11bccd735f7e8415ac6444b667 ]
    
    ACPICA commit 180cb53963aa876c782a6f52cc155d951b26051a
    
    According to the ACPI spec, _CID returns a package containing
    hardware ID's. Each element of an ASL package contains a reference
    count from the parent package as well as the element itself.
    
    Name (TEST, Package() {
        "String object" // this package element has a reference count of 2
    })
    
    A memory leak was caused in the _CID repair function because it did
    not decrement the reference count created by the package. Fix the
    memory leak by calling acpi_ut_remove_reference on _CID package elements
    that represent a hardware ID (_HID).
    
    Link: https://github.com/acpica/acpica/commit/180cb539
    Tested-by: Shawn Guo <shawn.guo@linaro.org>
    Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af02ec6cf6142bff7a2497c7fee83d0386379953
Author: Alexander Aring <aahringo@redhat.com>
Date:   Wed Jun 2 09:45:16 2021 -0400

    fs: dlm: fix memory leak when fenced
    
    [ Upstream commit 700ab1c363c7b54c9ea3222379b33fc00ab02f7b ]
    
    I got some kmemleak report when a node was fenced. The user space tool
    dlm_controld will therefore run some rmdir() in dlm configfs which was
    triggering some memleaks. This patch stores the sps and cms attributes
    which stores some handling for subdirectories of the configfs cluster
    entry and free them if they get released as the parent directory gets
    freed.
    
    unreferenced object 0xffff88810d9e3e00 (size 192):
      comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 73 70 61 63 65 73 00 00  ........spaces..
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000db8b640b>] make_cluster+0x5d/0x360
        [<000000006a571db4>] configfs_mkdir+0x274/0x730
        [<00000000b094501c>] vfs_mkdir+0x27e/0x340
        [<0000000058b0adaf>] do_mkdirat+0xff/0x1b0
        [<00000000d1ffd156>] do_syscall_64+0x40/0x80
        [<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    unreferenced object 0xffff88810d9e3a00 (size 192):
      comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 63 6f 6d 6d 73 00 00 00  ........comms...
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000a7ef6ad2>] make_cluster+0x82/0x360
        [<000000006a571db4>] configfs_mkdir+0x274/0x730
        [<00000000b094501c>] vfs_mkdir+0x27e/0x340
        [<0000000058b0adaf>] do_mkdirat+0xff/0x1b0
        [<00000000d1ffd156>] do_syscall_64+0x40/0x80
        [<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7fb82d7854198d15ee3f87c255e10ec8c9fe0347
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Tue May 25 13:20:12 2021 +0100

    random32: Fix implicit truncation warning in prandom_seed_state()
    
    [ Upstream commit d327ea15a305024ef0085252fa3657bbb1ce25f5 ]
    
    sparse generates the following warning:
    
     include/linux/prandom.h:114:45: sparse: sparse: cast truncates bits from
     constant value
    
    This is because the 64-bit seed value is manipulated and then placed in a
    u32, causing an implicit cast and truncation. A forced cast to u32 doesn't
    prevent this warning, which is reasonable because a typecast doesn't prove
    that truncation was expected.
    
    Logical-AND the value with 0xffffffff to make explicit that truncation to
    32-bit is intended.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20210525122012.6336-3-rf@opensource.cirrus.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5473f43e4fb27550512bebf62d029f4850b4b3d
Author: Alexander Aring <aahringo@redhat.com>
Date:   Fri May 21 15:08:38 2021 -0400

    fs: dlm: cancel work sync othercon
    
    [ Upstream commit c6aa00e3d20c2767ba3f57b64eb862572b9744b3 ]
    
    These rx tx flags arguments are for signaling close_connection() from
    which worker they are called. Obviously the receive worker cannot cancel
    itself and vice versa for swork. For the othercon the receive worker
    should only be used, however to avoid deadlocks we should pass the same
    flags as the original close_connection() was called.
    
    Signed-off-by: Alexander Aring <aahringo@redhat.com>
    Signed-off-by: David Teigland <teigland@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 96a6185a9f0966347d7133268d824c8cf09ebbf3
Author: zhangyi (F) <yi.zhang@huawei.com>
Date:   Sat Mar 13 11:01:44 2021 +0800

    block_dump: remove block_dump feature in mark_inode_dirty()
    
    [ Upstream commit 12e0613715e1cf305fffafaf0e89d810d9a85cc0 ]
    
    block_dump is an old debugging interface, one of it's functions is used
    to print the information about who write which file on disk. If we
    enable block_dump through /proc/sys/vm/block_dump and turn on debug log
    level, we can gather information about write process name, target file
    name and disk from kernel message. This feature is realized in
    block_dump___mark_inode_dirty(), it print above information into kernel
    message directly when marking inode dirty, so it is noisy and can easily
    trigger log storm. At the same time, get the dentry refcount is also not
    safe, we found it will lead to deadlock on ext4 file system with
    data=journal mode.
    
    After tracepoints has been introduced into the kernel, we got a
    tracepoint in __mark_inode_dirty(), which is a better replacement of
    block_dump___mark_inode_dirty(). The only downside is that it only trace
    the inode number and not a file name, but it probably doesn't matter
    because the original printed file name in block_dump is not accurate in
    some cases, and we can still find it through the inode number and device
    id. So this patch delete the dirting inode part of block_dump feature.
    
    Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20210313030146.2882027-2-yi.zhang@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4a5cdb908e425335641f795eb3e88f601b0d7be5
Author: Chris Chiu <chris.chiu@canonical.com>
Date:   Thu May 20 11:09:50 2021 +0800

    ACPI: EC: Make more Asus laptops use ECDT _GPE
    
    [ Upstream commit 6306f0431914beaf220634ad36c08234006571d5 ]
    
    More ASUS laptops have the _GPE define in the DSDT table with a
    different value than the _GPE number in the ECDT.
    
    This is causing media keys not working on ASUS X505BA/BP, X542BA/BP
    
    Add model info to the quirks list.
    
    Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
    Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8278bf4874aac63527e32f010d411e05a66d1953
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Fri May 14 17:12:04 2021 +0100

    lib: vsprintf: Fix handling of number field widths in vsscanf
    
    [ Upstream commit 900fdc4573766dd43b847b4f54bd4a1ee2bc7360 ]
    
    The existing code attempted to handle numbers by doing a strto[u]l(),
    ignoring the field width, and then repeatedly dividing to extract the
    field out of the full converted value. If the string contains a run of
    valid digits longer than will fit in a long or long long, this would
    overflow and no amount of dividing can recover the correct value.
    
    This patch fixes vsscanf() to obey number field widths when parsing
    the number.
    
    A new _parse_integer_limit() is added that takes a limit for the number
    of characters to parse. The number field conversion in vsscanf is changed
    to use this new function.
    
    If a number starts with a radix prefix, the field width  must be long
    enough for at last one digit after the prefix. If not, it will be handled
    like this:
    
     sscanf("0x4", "%1i", &i): i=0, scanning continues with the 'x'
     sscanf("0x4", "%2i", &i): i=0, scanning continues with the '4'
    
    This is consistent with the observed behaviour of userland sscanf.
    
    Note that this patch does NOT fix the problem of a single field value
    overflowing the target type. So for example:
    
      sscanf("123456789abcdef", "%x", &i);
    
    Will not produce the correct result because the value obviously overflows
    INT_MAX. But sscanf will report a successful conversion.
    
    Note that where a very large number is used to mean "unlimited", the value
    INT_MAX is used for consistency with the behaviour of vsnprintf().
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20210514161206.30821-2-rf@opensource.cirrus.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1aa9139dd73bfa60135207a50ac17b2ddc2b999
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Fri May 14 15:01:16 2021 +0800

    hv_utils: Fix passing zero to 'PTR_ERR' warning
    
    [ Upstream commit c6a8625fa4c6b0a97860d053271660ccedc3d1b3 ]
    
    Sparse warn this:
    
    drivers/hv/hv_util.c:753 hv_timesync_init() warn:
     passing zero to 'PTR_ERR'
    
    Use PTR_ERR_OR_ZERO instead of PTR_ERR to fix this.
    
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20210514070116.16800-1-yuehaibing@huawei.com
    [ wei: change %ld to %d ]
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 33f09d202e851ded5d1d9db1b059388da33f2361
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Wed May 12 17:15:14 2021 -0500

    ACPI: processor idle: Fix up C-state latency if not ordered
    
    [ Upstream commit 65ea8f2c6e230bdf71fed0137cf9e9d1b307db32 ]
    
    Generally, the C-state latency is provided by the _CST method or
    FADT, but some OEM platforms using AMD Picasso, Renoir, Van Gogh,
    and Cezanne set the C2 latency greater than C3's which causes the
    C2 state to be skipped.
    
    That will block the core entering PC6, which prevents S0ix working
    properly on Linux systems.
    
    In other operating systems, the latency values are not validated and
    this does not cause problems by skipping states.
    
    To avoid this issue on Linux, detect when latencies are not an
    arithmetic progression and sort them.
    
    Link: https://gitlab.freedesktop.org/agd5f/linux/-/commit/026d186e4592c1ee9c1cb44295912d0294508725
    Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1230#note_712174
    Suggested-by: Prike Liang <Prike.Liang@amd.com>
    Suggested-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    [ rjw: Subject and changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 413d1eadc3c069c0687ba03cd30425798ef29a26
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Wed May 12 11:37:27 2021 +0800

    EDAC/ti: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 0a37f32ba5272b2d4ec8c8d0f6b212b81b578f7e ]
    
    The module misses MODULE_DEVICE_TABLE() for of_device_id tables and thus
    never autoloads on ID matches.
    
    Add the missing declaration.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Cc: Tero Kristo <kristo@kernel.org>
    Link: https://lkml.kernel.org/r/20210512033727.26701-1-cuibixuan@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit eb38cd3037d00267297f3f5635dd19dc54353ad1
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Mar 19 17:27:16 2021 -0700

    HID: do not use down_interruptible() when unbinding devices
    
    [ Upstream commit f2145f8dc566c4f3b5a8deb58dcd12bed4e20194 ]
    
    Action of unbinding driver from a device is not cancellable and should not
    fail, and driver core does not pay attention to the result of "remove"
    method, therefore using down_interruptible() in hid_device_remove() does
    not make sense.
    
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0644482130a6bb2e9e7ccbfc93563e7f04c99693
Author: Axel Lin <axel.lin@ingics.com>
Date:   Fri Jun 18 22:14:11 2021 +0800

    regulator: da9052: Ensure enough delay time for .set_voltage_time_sel
    
    [ Upstream commit a336dc8f683e5be794186b5643cd34cb28dd2c53 ]
    
    Use DIV_ROUND_UP to prevent truncation by integer division issue.
    This ensures we return enough delay time.
    
    Also fix returning negative value when new_sel < old_sel.
    
    Signed-off-by: Axel Lin <axel.lin@ingics.com>
    Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7333841bae6e58e32e76f49541785e872dcc0ee0
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Thu Jun 10 05:23:02 2021 +0000

    btrfs: disable build on platforms having page size 256K
    
    [ Upstream commit b05fbcc36be1f8597a1febef4892053a0b2f3f60 ]
    
    With a config having PAGE_SIZE set to 256K, BTRFS build fails
    with the following message
    
      include/linux/compiler_types.h:326:38: error: call to
      '__compiletime_assert_791' declared with attribute error:
      BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0
    
    BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with
    256K pages at the time being.
    
    There are two platforms that can select 256K pages:
     - hexagon
     - powerpc
    
    Disable BTRFS when 256K page size is selected. Supporting this would
    require changes to the subpage mode that's currently being developed.
    Given that 256K is many times larger than page sizes commonly used and
    for what the algorithms and structures have been tuned, it's out of
    scope and disabling build is a reasonable option.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    [ update changelog ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 41a5f2820aaa24281818143d9f1fafd6b438f944
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri May 21 16:44:09 2021 -0400

    btrfs: abort transaction if we fail to update the delayed inode
    
    [ Upstream commit 04587ad9bef6ce9d510325b4ba9852b6129eebdb ]
    
    If we fail to update the delayed inode we need to abort the transaction,
    because we could leave an inode with the improper counts or some other
    such corruption behind.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5a9e95173b9ebe9943ac6858e0143f96dc02b16b
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri May 21 16:44:08 2021 -0400

    btrfs: fix error handling in __btrfs_update_delayed_inode
    
    [ Upstream commit bb385bedded3ccbd794559600de4a09448810f4a ]
    
    If we get an error while looking up the inode item we'll simply bail
    without cleaning up the delayed node.  This results in this style of
    warning happening on commit:
    
      WARNING: CPU: 0 PID: 76403 at fs/btrfs/delayed-inode.c:1365 btrfs_assert_delayed_root_empty+0x5b/0x90
      CPU: 0 PID: 76403 Comm: fsstress Tainted: G        W         5.13.0-rc1+ #373
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
      RIP: 0010:btrfs_assert_delayed_root_empty+0x5b/0x90
      RSP: 0018:ffffb8bb815a7e50 EFLAGS: 00010286
      RAX: 0000000000000000 RBX: ffff95d6d07e1888 RCX: ffff95d6c0fa3000
      RDX: 0000000000000002 RSI: 000000000029e91c RDI: ffff95d6c0fc8060
      RBP: ffff95d6c0fc8060 R08: 00008d6d701a2c1d R09: 0000000000000000
      R10: ffff95d6d1760ea0 R11: 0000000000000001 R12: ffff95d6c15a4d00
      R13: ffff95d6c0fa3000 R14: 0000000000000000 R15: ffffb8bb815a7e90
      FS:  00007f490e8dbb80(0000) GS:ffff95d73bc00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f6e75555cb0 CR3: 00000001101ce001 CR4: 0000000000370ef0
      Call Trace:
       btrfs_commit_transaction+0x43c/0xb00
       ? finish_wait+0x80/0x80
       ? vfs_fsync_range+0x90/0x90
       iterate_supers+0x8c/0x100
       ksys_sync+0x50/0x90
       __do_sys_sync+0xa/0x10
       do_syscall_64+0x3d/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
    
    Because the iref isn't dropped and this leaves an elevated node->count,
    so any release just re-queues it onto the delayed inodes list.  Fix this
    by going to the out label to handle the proper cleanup of the delayed
    node.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 279dccd556cd780d0ad23ea0d25c9ed231bc187c
Author: Steve Longerbeam <slongerbeam@gmail.com>
Date:   Mon May 17 16:29:23 2021 +0200

    media: imx-csi: Skip first few frames from a BT.656 source
    
    [ Upstream commit e198be37e52551bb863d07d2edc535d0932a3c4f ]
    
    Some BT.656 sensors (e.g. ADV718x) transmit frames with unstable BT.656
    sync codes after initial power on. This confuses the imx CSI,resulting
    in vertical and/or horizontal sync issues. Skip the first 20 frames
    to avoid the unstable sync codes.
    
    [fabio: fixed checkpatch warning and increased the frame skipping to 20]
    
    Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com>
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2f6d707fab64ddfebfb65cc4dacfee9d19ad03a8
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Thu Jun 10 08:57:02 2021 +0200

    media: siano: fix device register error path
    
    [ Upstream commit 5368b1ee2939961a16e74972b69088433fc52195 ]
    
    As reported by smatch:
            drivers/media/common/siano/smsdvb-main.c:1231 smsdvb_hotplug() warn: '&client->entry' not removed from list
    
    If an error occur at the end of the registration logic, it won't
    drop the device from the list.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5f6f52d667c7fcfd36f534e542b2c3bdaea1b5ff
Author: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Date:   Wed Jun 16 13:13:54 2021 +0200

    media: dvb_net: avoid speculation from net slot
    
    [ Upstream commit abc0226df64dc137b48b911c1fe4319aec5891bb ]
    
    The risk of especulation is actually almost-non-existing here,
    as there are very few users of TCP/IP using the DVB stack,
    as, this is mainly used with DVB-S/S2 cards, and only by people
    that receives TCP/IP from satellite connections, which limits
    a lot the number of users of such feature(*).
    
    (*) In thesis, DVB-C cards could also benefit from it, but I'm
    yet to see a hardware that supports it.
    
    Yet, fixing it is trivial.
    
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0c4c098c0405b364310d4021ac1f59f611c59538
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Thu Jun 10 08:21:50 2021 +0200

    crypto: shash - avoid comparing pointers to exported functions under CFI
    
    [ Upstream commit 22ca9f4aaf431a9413dcc115dd590123307f274f ]
    
    crypto_shash_alg_has_setkey() is implemented by testing whether the
    .setkey() member of a struct shash_alg points to the default version,
    called shash_no_setkey(). As crypto_shash_alg_has_setkey() is a static
    inline, this requires shash_no_setkey() to be exported to modules.
    
    Unfortunately, when building with CFI, function pointers are routed
    via CFI stubs which are private to each module (or to the kernel proper)
    and so this function pointer comparison may fail spuriously.
    
    Let's fix this by turning crypto_shash_alg_has_setkey() into an out of
    line function.
    
    Cc: Sami Tolvanen <samitolvanen@google.com>
    Cc: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f7000d0d10af58cbd71269912da558b57d0442c0
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Thu Jun 3 13:33:20 2021 +0000

    mmc: via-sdmmc: add a check against NULL pointer dereference
    
    [ Upstream commit 45c8ddd06c4b729c56a6083ab311bfbd9643f4a6 ]
    
    Before referencing 'host->data', the driver needs to check whether it is
    null pointer, otherwise it will cause a null pointer reference.
    
    This log reveals it:
    
    [   29.355199] BUG: kernel NULL pointer dereference, address:
    0000000000000014
    [   29.357323] #PF: supervisor write access in kernel mode
    [   29.357706] #PF: error_code(0x0002) - not-present page
    [   29.358088] PGD 0 P4D 0
    [   29.358280] Oops: 0002 [#1] PREEMPT SMP PTI
    [   29.358595] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-
    g70e7f0549188-dirty #102
    [   29.359164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
    BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    [   29.359978] RIP: 0010:via_sdc_isr+0x21f/0x410
    [   29.360314] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00
    10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43
    18 <c7> 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77
    [   29.361661] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046
    [   29.362042] RAX: 0000000000000000 RBX: ffff888107d77880
    RCX: 0000000000000000
    [   29.362564] RDX: 0000000000000000 RSI: ffffffff835d20bb
    RDI: 00000000ffffffff
    [   29.363085] RBP: ffffc90000118ed8 R08: 0000000000000001
    R09: 0000000000000001
    [   29.363604] R10: 0000000000000000 R11: 0000000000000001
    R12: 0000000000008600
    [   29.364128] R13: ffff888107d779c8 R14: ffffc90009c00200
    R15: 0000000000008000
    [   29.364651] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000)
    knlGS:0000000000000000
    [   29.365235] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   29.365655] CR2: 0000000000000014 CR3: 0000000005a2e000
    CR4: 00000000000006e0
    [   29.366170] DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000
    [   29.366683] DR3: 0000000000000000 DR6: 00000000fffe0ff0
    DR7: 0000000000000400
    [   29.367197] Call Trace:
    [   29.367381]  <IRQ>
    [   29.367537]  __handle_irq_event_percpu+0x53/0x3e0
    [   29.367916]  handle_irq_event_percpu+0x35/0x90
    [   29.368247]  handle_irq_event+0x39/0x60
    [   29.368632]  handle_fasteoi_irq+0xc2/0x1d0
    [   29.368950]  __common_interrupt+0x7f/0x150
    [   29.369254]  common_interrupt+0xb4/0xd0
    [   29.369547]  </IRQ>
    [   29.369708]  asm_common_interrupt+0x1e/0x40
    [   29.370016] RIP: 0010:native_safe_halt+0x17/0x20
    [   29.370360] Code: 07 0f 00 2d db 80 43 00 f4 5d c3 0f 1f 84 00 00 00
    00 00 8b 05 c2 37 e5 01 55 48 89 e5 85 c0 7e 07 0f 00 2d bb 80 43 00 fb
    f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d f9 91
    [   29.371696] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246
    [   29.372079] RAX: 0000000000000000 RBX: 0000000000000002
    RCX: 0000000000000000
    [   29.372595] RDX: 0000000000000000 RSI: ffffffff854f67a4
    RDI: ffffffff85403406
    [   29.373122] RBP: ffffc9000008fe90 R08: 0000000000000001
    R09: 0000000000000001
    [   29.373646] R10: 0000000000000000 R11: 0000000000000001
    R12: ffffffff86009188
    [   29.374160] R13: 0000000000000000 R14: 0000000000000000
    R15: ffff888100258000
    [   29.374690]  default_idle+0x9/0x10
    [   29.374944]  arch_cpu_idle+0xa/0x10
    [   29.375198]  default_idle_call+0x6e/0x250
    [   29.375491]  do_idle+0x1f0/0x2d0
    [   29.375740]  cpu_startup_entry+0x18/0x20
    [   29.376034]  start_secondary+0x11f/0x160
    [   29.376328]  secondary_startup_64_no_verify+0xb0/0xbb
    [   29.376705] Modules linked in:
    [   29.376939] Dumping ftrace buffer:
    [   29.377187]    (ftrace buffer empty)
    [   29.377460] CR2: 0000000000000014
    [   29.377712] ---[ end trace 51a473dffb618c47 ]---
    [   29.378056] RIP: 0010:via_sdc_isr+0x21f/0x410
    [   29.378380] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00
    10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43
    18 <c7> 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77
    [   29.379714] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046
    [   29.380098] RAX: 0000000000000000 RBX: ffff888107d77880
    RCX: 0000000000000000
    [   29.380614] RDX: 0000000000000000 RSI: ffffffff835d20bb
    RDI: 00000000ffffffff
    [   29.381134] RBP: ffffc90000118ed8 R08: 0000000000000001
    R09: 0000000000000001
    [   29.381653] R10: 0000000000000000 R11: 0000000000000001
    R12: 0000000000008600
    [   29.382176] R13: ffff888107d779c8 R14: ffffc90009c00200
    R15: 0000000000008000
    [   29.382697] FS:  0000000000000000(0000) GS:ffff88817bc80000(0000)
    knlGS:0000000000000000
    [   29.383277] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   29.383697] CR2: 0000000000000014 CR3: 0000000005a2e000
    CR4: 00000000000006e0
    [   29.384223] DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000
    [   29.384736] DR3: 0000000000000000 DR6: 00000000fffe0ff0
    DR7: 0000000000000400
    [   29.385260] Kernel panic - not syncing: Fatal exception in interrupt
    [   29.385882] Dumping ftrace buffer:
    [   29.386135]    (ftrace buffer empty)
    [   29.386401] Kernel Offset: disabled
    [   29.386656] Rebooting in 1 seconds..
    
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Link: https://lore.kernel.org/r/1622727200-15808-1-git-send-email-zheyuma97@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a3c67e5a5266d29fe269c16c88433f55d8e5b80b
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Tue May 25 15:06:52 2021 +0200

    media: dvd_usb: memory leak in cinergyt2_fe_attach
    
    [ Upstream commit 9ad1efee086e0e913914fa2b2173efb830bad68c ]
    
    When the driver fails to talk with the hardware with dvb_usb_generic_rw,
    it will return an error to dvb_usb_adapter_frontend_init. However, the
    driver forgets to free the resource (e.g., struct cinergyt2_fe_state),
    which leads to a memory leak.
    
    Fix this by freeing struct cinergyt2_fe_state when dvb_usb_generic_rw
    fails in cinergyt2_frontend_attach.
    
    backtrace:
      [<0000000056e17b1a>] kmalloc include/linux/slab.h:552 [inline]
      [<0000000056e17b1a>] kzalloc include/linux/slab.h:682 [inline]
      [<0000000056e17b1a>] cinergyt2_fe_attach+0x21/0x80 drivers/media/usb/dvb-usb/cinergyT2-fe.c:271
      [<00000000ae0b1711>] cinergyt2_frontend_attach+0x21/0x70 drivers/media/usb/dvb-usb/cinergyT2-core.c:74
      [<00000000d0254861>] dvb_usb_adapter_frontend_init+0x11b/0x1b0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
      [<0000000002e08ac6>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:84 [inline]
      [<0000000002e08ac6>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline]
      [<0000000002e08ac6>] dvb_usb_device_init.cold+0x4d0/0x6ae drivers/media/usb/dvb-usb/dvb-usb-init.c:287
    
    Reported-by: syzbot+e1de8986786b3722050e@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 83dd29dad7da5b7b54429f89624556e368d1891f
Author: Evgeny Novikov <novikov@ispras.ru>
Date:   Wed May 19 14:04:49 2021 +0200

    media: st-hva: Fix potential NULL pointer dereferences
    
    [ Upstream commit b7fdd208687ba59ebfb09b2199596471c63b69e3 ]
    
    When ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread() it tries to
    access fields of ctx that is NULL at that point. The patch gets rid of
    these accesses.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fcf6b8f56302d3882b3b76b1b97ccf68ad573c38
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Wed May 12 17:18:36 2021 +0200

    media: bt8xx: Fix a missing check bug in bt878_probe
    
    [ Upstream commit 1a4520090681853e6b850cbe54b27247a013e0e5 ]
    
    In 'bt878_irq', the driver calls 'tasklet_schedule', but this tasklet is
    set in 'dvb_bt8xx_load_card' of another driver 'dvb-bt8xx'.
    However, this two drivers are separate. The user may not load the
    'dvb-bt8xx' driver when loading the 'bt8xx' driver, that is, the tasklet
    has not been initialized when 'tasklet_schedule' is called, so it is
    necessary to check whether the tasklet is initialized in 'bt878_probe'.
    
    Fix this by adding a check at the end of bt878_probe.
    
    The KASAN's report reveals it:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    PGD 800000006aab2067 P4D 800000006aab2067 PUD 6b2ea067 PMD 0
    Oops: 0010 [#1] PREEMPT SMP KASAN PTI
    CPU: 2 PID: 8724 Comm: syz-executor.0 Not tainted 4.19.177-
    gdba4159c14ef-dirty #40
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-
    gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    RIP: 0010:          (null)
    Code: Bad RIP value.
    RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246
    RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000
    RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774
    R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000
    R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90
    FS:  00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS:
    0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <IRQ>
     tasklet_action_common.isra.17+0x141/0x420 kernel/softirq.c:522
     tasklet_action+0x50/0x70 kernel/softirq.c:540
     __do_softirq+0x224/0x92c kernel/softirq.c:292
     invoke_softirq kernel/softirq.c:372 [inline]
     irq_exit+0x15a/0x180 kernel/softirq.c:412
     exiting_irq arch/x86/include/asm/apic.h:535 [inline]
     do_IRQ+0x123/0x1e0 arch/x86/kernel/irq.c:260
     common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
     </IRQ>
    RIP: 0010:__do_sys_interrupt kernel/sys.c:2593 [inline]
    RIP: 0010:__se_sys_interrupt kernel/sys.c:2584 [inline]
    RIP: 0010:__x64_sys_interrupt+0x5b/0x80 kernel/sys.c:2584
    Code: ba 00 04 00 00 48 c7 c7 c0 99 31 8c e8 ae 76 5e 01 48 85 c0 75 21 e8
    14 ae 24 00 48 c7 c3 c0 99 31 8c b8 0c 00 00 00 0f 01 c1 <31> db e8 fe ad
    24 00 48 89 d8 5b 5d c3 48 c7 c3 ea ff ff ff eb ec
    RSP: 0018:ffff888054167f10 EFLAGS: 00000212 ORIG_RAX: ffffffffffffffde
    RAX: 000000000000000c RBX: ffffffff8c3199c0 RCX: ffffc90001ca6000
    RDX: 000000000000001a RSI: ffffffff813478fc RDI: ffffffff8c319dc0
    RBP: ffff888054167f18 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000080 R11: fffffbfff18633b7 R12: ffff888054167f58
    R13: ffff88805f638000 R14: 0000000000000000 R15: 0000000000000000
     do_syscall_64+0xb0/0x4e0 arch/x86/entry/common.c:293
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x4692a9
    Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7
    48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
    ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f6b550e5c48 EFLAGS: 00000246 ORIG_RAX: 000000000000014f
    RAX: ffffffffffffffda RBX: 000000000077bf60 RCX: 00000000004692a9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140
    RBP: 00000000004cf7eb R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf60
    R13: 0000000000000000 R14: 000000000077bf60 R15: 00007fff55a1dca0
    Modules linked in:
    Dumping ftrace buffer:
       (ftrace buffer empty)
    CR2: 0000000000000000
    ---[ end trace 68e5849c3f77cbb6 ]---
    RIP: 0010:          (null)
    Code: Bad RIP value.
    RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246
    RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000
    RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774
    R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000
    R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90
    FS:  00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS:
    0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Reported-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c7c1d06ec164d1e05635eafddf1594eda86d6b9a
Author: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
Date:   Sun May 9 10:24:02 2021 +0200

    media: v4l2-core: Avoid the dangling pointer in v4l2_fh_release
    
    [ Upstream commit 7dd0c9e547b6924e18712b6b51aa3cba1896ee2c ]
    
    A use after free bug caused by the dangling pointer
    filp->privitate_data in v4l2_fh_release.
    See https://lore.kernel.org/patchwork/patch/1419058/.
    
    My patch sets the dangling pointer to NULL to provide
    robust.
    
    Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cd16b8a5536dfdd7f190592e7eee9c0a68743100
Author: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Date:   Tue May 4 20:32:49 2021 +0200

    media: em28xx: Fix possible memory leak of em28xx struct
    
    [ Upstream commit ac5688637144644f06ed1f3c6d4dd8bb7db96020 ]
    
    The em28xx struct kref isn't being decreased after an error in the
    em28xx_ir_init, leading to a possible memory leak.
    
    A kref_put and em28xx_shutdown_buttons is added to the error handler code.
    
    Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9b808bdcc936be3503e5141879beb1cbd693d984
Author: Odin Ugedal <odin@uged.al>
Date:   Tue May 18 14:52:02 2021 +0200

    sched/fair: Fix ascii art by relpacing tabs
    
    [ Upstream commit 08f7c2f4d0e9f4283f5796b8168044c034a1bfcb ]
    
    When using something other than 8 spaces per tab, this ascii art
    makes not sense, and the reader might end up wondering what this
    advanced equation "is".
    
    Signed-off-by: Odin Ugedal <odin@uged.al>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lkml.kernel.org/r/20210518125202.78658-4-odin@uged.al
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e6663c59b0563a2377dbfef9b2a0d85172baa34e
Author: Jack Xu <jack.xu@intel.com>
Date:   Mon May 17 05:13:16 2021 -0400

    crypto: qat - remove unused macro in FW loader
    
    [ Upstream commit 9afe77cf25d9670e61b489fd52cc6f75fd7f6803 ]
    
    Remove the unused macro ICP_DH895XCC_PESRAM_BAR_SIZE in the firmware
    loader.
    
    This is to fix the following warning when compiling the driver using the
    clang compiler with CC=clang W=2:
    
        drivers/crypto/qat/qat_common/qat_uclo.c:345:9: warning: macro is not used [-Wunused-macros]
    
    Signed-off-by: Jack Xu <jack.xu@intel.com>
    Co-developed-by: Zhehui Xiang <zhehui.xiang@intel.com>
    Signed-off-by: Zhehui Xiang <zhehui.xiang@intel.com>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 536b11e382d888eaf2009f10171e986e37352d14
Author: Jack Xu <jack.xu@intel.com>
Date:   Mon May 17 05:13:15 2021 -0400

    crypto: qat - check return code of qat_hal_rd_rel_reg()
    
    [ Upstream commit 96b57229209490c8bca4335b01a426a96173dc56 ]
    
    Check the return code of the function qat_hal_rd_rel_reg() and return it
    to the caller.
    
    This is to fix the following warning when compiling the driver with
    clang scan-build:
    
        drivers/crypto/qat/qat_common/qat_hal.c:1436:2: warning: 6th function call argument is an uninitialized value
    
    Signed-off-by: Jack Xu <jack.xu@intel.com>
    Co-developed-by: Zhehui Xiang <zhehui.xiang@intel.com>
    Signed-off-by: Zhehui Xiang <zhehui.xiang@intel.com>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0983e01de0ec33b7f2e63ad866d68090b003701c
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Tue May 4 19:08:58 2021 +0200

    media: pvrusb2: fix warning in pvr2_i2c_core_done
    
    [ Upstream commit f8194e5e63fdcb349e8da9eef9e574d5b1d687cb ]
    
    syzbot has reported the following warning in pvr2_i2c_done:
    
            sysfs group 'power' not found for kobject '1-0043'
    
    When the device is disconnected (pvr_hdw_disconnect), the i2c adapter is
    not unregistered along with the USB and v4l2 teardown. As part of the USB
    device disconnect, the sysfs files of the subdevices are also deleted.
    So, by the time pvr_i2c_core_done is called by pvr_context_destroy, the
    sysfs files have been deleted.
    
    To fix this, unregister the i2c adapter too in pvr_hdw_disconnect. Make
    the device deregistration code shared by calling pvr_hdw_disconnect from
    pvr2_hdw_destroy.
    
    Reported-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
    Tested-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c93a0890e9551698f24553381c44dafd6c90275b
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Apr 23 10:00:49 2021 +0200

    media: cobalt: fix race condition in setting HPD
    
    [ Upstream commit 3d37ef41bed0854805ab9af22c422267510e1344 ]
    
    The cobalt_s_bit_sysctrl reads the old register value over PCI,
    then changes a bit and sets writes the new value to the register.
    
    This is used among other things for setting the HPD output pin.
    
    But if the HPD is changed for multiple inputs at the same time,
    then this causes a race condition where a stale value is read.
    
    Serialize this function with a mutex.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0f56cbfad6e68ecfaec3b15098b0a1cf6e22c239
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Wed Apr 21 21:43:45 2021 +0200

    media: cpia2: fix memory leak in cpia2_usb_probe
    
    [ Upstream commit be8656e62e9e791837b606a027802b504a945c97 ]
    
    syzbot reported leak in cpia2 usb driver. The problem was
    in invalid error handling.
    
    v4l2_device_register() is called in cpia2_init_camera_struct(), but
    all error cases after cpia2_init_camera_struct() did not call the
    v4l2_device_unregister()
    
    Reported-by: syzbot+d1e69c888f0d3866ead4@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 21f19e32e797981128fee8318641be7b031d681e
Author: Bixuan Cui <cuibixuan@huawei.com>
Date:   Sat May 8 11:14:55 2021 +0800

    crypto: nx - add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 06676aa1f455c74e3ad1624cea3acb9ed2ef71ae ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7b4c8073fb05e0f0320359b74ffc5218b2b5ea6d
Author: Zou Wei <zou_wei@huawei.com>
Date:   Tue May 11 11:53:18 2021 +0800

    regulator: uniphier: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit d019f38a1af3c6015cde6a47951a3ec43beeed80 ]
    
    This patch adds missing MODULE_DEVICE_TABLE definition which generates
    correct modalias for automatic loading of this driver when it is built
    as an external module.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Signed-off-by: Zou Wei <zou_wei@huawei.com>
    Link: https://lore.kernel.org/r/1620705198-104566-1-git-send-email-zou_wei@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a741b1bd7068ed8a750f9240d4e17c93f1b22a25
Author: Tian Tao <tiantao6@hisilicon.com>
Date:   Thu Apr 29 19:20:48 2021 +0800

    spi: omap-100k: Fix the length judgment problem
    
    [ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ]
    
    word_len should be checked in the omap1_spi100k_setup_transfer
    function to see if it exceeds 32.
    
    Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
    Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 880ec021ed3b665014b74784311cb8b5bc736854
Author: Jay Fang <f.fangjian@huawei.com>
Date:   Thu May 6 15:08:08 2021 +0800

    spi: spi-topcliff-pch: Fix potential double free in pch_spi_process_messages()
    
    [ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ]
    
    pch_spi_set_tx() frees data->pkt_tx_buff on failure of kzalloc() for
    data->pkt_rx_buff, but its caller, pch_spi_process_messages(), will
    free data->pkt_tx_buff again. Set data->pkt_tx_buff to NULL after
    kfree() to avoid double free.
    
    Signed-off-by: Jay Fang <f.fangjian@huawei.com>
    Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffd424a94a44418714dfedeb5fc091e63e4ae1ad
Author: Jay Fang <f.fangjian@huawei.com>
Date:   Mon May 10 14:58:23 2021 +0800

    spi: spi-loopback-test: Fix 'tx_buf' might be 'rx_buf'
    
    [ Upstream commit 9e37a3ab0627011fb63875e9a93094b6fc8ddf48 ]
    
    In function 'spi_test_run_iter': Value 'tx_buf' might be 'rx_buf'.
    
    Signed-off-by: Jay Fang <f.fangjian@huawei.com>
    Link: https://lore.kernel.org/r/1620629903-15493-5-git-send-email-f.fangjian@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 878c5d126b8e2c4b7b3b1a69288c0866d38774a8
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Wed Apr 21 11:14:02 2021 +0100

    spi: Make of_register_spi_device also set the fwnode
    
    [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ]
    
    Currently, the SPI core doesn't set the struct device fwnode pointer
    when it creates a new SPI device. This means when the device is
    registered the fwnode is NULL and the check in device_add which sets
    the fwnode->dev pointer is skipped. This wasn't previously an issue,
    however these two patches:
    
    commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
    fw_devlink=on by default")
    commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the
    primary device")
    
    Added some code to the GPIO core which relies on using that
    fwnode->dev pointer to determine if a driver is bound to the fwnode
    and if not bind a stub GPIO driver. This means the GPIO providers
    behind SPI will get both the expected driver and this stub driver
    causing the stub driver to fail if it attempts to request any pin
    configuration. For example on my system:
    
    madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3
    madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22
    madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1  on device madera-pinctrl
    gpio_stub_drv gpiochip3: Error applying setting, reverse things back
    gpio_stub_drv: probe of gpiochip3 failed with error -22
    
    The firmware node on the device created by the GPIO framework is set
    through the of_node pointer hence things generally actually work,
    however that fwnode->dev is never set, as the check was skipped at
    device_add time. This fix appears to match how the I2C subsystem
    handles the same situation.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1c37784a00edfb88be67b24f7e776cda9eb803fd
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jun 22 09:15:35 2021 +0200

    fuse: check connected before queueing on fpq->io
    
    commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream.
    
    A request could end up on the fpq->io list after fuse_abort_conn() has
    reset fpq->connected and aborted requests on that list:
    
    Thread-1                          Thread-2
    ========                          ========
    ->fuse_simple_request()           ->shutdown
      ->__fuse_request_send()
        ->queue_request()           ->fuse_abort_conn()
    ->fuse_dev_do_read()                ->acquire(fpq->lock)
      ->wait_for(fpq->lock)           ->set err to all req's in fpq->io
                                      ->release(fpq->lock)
      ->acquire(fpq->lock)
      ->add req to fpq->io
    
    After the userspace copy is done the request will be ended, but
    req->out.h.error will remain uninitialized.  Also the copy might block
    despite being already aborted.
    
    Fix both issues by not allowing the request to be queued on the fpq->io
    list after fuse_abort_conn() has processed this list.
    
    Reported-by: Pradeep P V K <pragalla@codeaurora.org>
    Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
    Cc: <stable@vger.kernel.org> # v4.2
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77c94b2a1deea733e2796a2da7b637c1afd0cdb8
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Fri May 14 17:27:44 2021 +0200

    evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded
    
    commit 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c upstream.
    
    EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to
    temporarily disable metadata verification until all xattrs/attrs necessary
    to verify an EVM portable signature are copied to the file. This flag is
    cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is
    calculated on unverified xattrs/attrs.
    
    Currently EVM unnecessarily denies setting this flag if EVM is initialized
    with a public key, which is not a concern as it cannot be used to trust
    xattrs/attrs updates. This patch removes this limitation.
    
    Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: stable@vger.kernel.org # 4.16.x
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c6b7016754559b1ead8d61e8ac67728d960fbbd
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Fri May 14 17:27:42 2021 +0200

    evm: Execute evm_inode_init_security() only when an HMAC key is loaded
    
    commit 9eea2904292c2d8fa98df141d3bf7c41ec9dc1b5 upstream.
    
    evm_inode_init_security() requires an HMAC key to calculate the HMAC on
    initial xattrs provided by LSMs. However, it checks generically whether a
    key has been loaded, including also public keys, which is not correct as
    public keys are not suitable to calculate the HMAC.
    
    Originally, support for signature verification was introduced to verify a
    possibly immutable initial ram disk, when no new files are created, and to
    switch to HMAC for the root filesystem. By that time, an HMAC key should
    have been loaded and usable to calculate HMACs for new files.
    
    More recently support for requiring an HMAC key was removed from the
    kernel, so that signature verification can be used alone. Since this is a
    legitimate use case, evm_inode_init_security() should not return an error
    when no HMAC key has been loaded.
    
    This patch fixes this problem by replacing the evm_key_loaded() check with
    a check of the EVM_INIT_HMAC flag in evm_initialized.
    
    Fixes: 26ddabfe96b ("evm: enable EVM when X509 certificate is loaded")
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Cc: stable@vger.kernel.org # 4.5.x
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ad332936f9825be2621ce4097ae2ea5622b1675
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Jun 25 16:28:41 2021 +1000

    powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()
    
    commit 7c6986ade69e3c81bac831645bc72109cd798a80 upstream.
    
    In raise_backtrace_ipi() we iterate through the cpumask of CPUs, sending
    each an IPI asking them to do a backtrace, but we don't wait for the
    backtrace to happen.
    
    We then iterate through the CPU mask again, and if any CPU hasn't done
    the backtrace and cleared itself from the mask, we print a trace on its
    behalf, noting that the trace may be "stale".
    
    This works well enough when a CPU is not responding, because in that
    case it doesn't receive the IPI and the sending CPU is left to print the
    trace. But when all CPUs are responding we are left with a race between
    the sending and receiving CPUs, if the sending CPU wins the race then it
    will erroneously print a trace.
    
    This leads to spurious "stale" traces from the sending CPU, which can
    then be interleaved messily with the receiving CPU, note the CPU
    numbers, eg:
    
      [ 1658.929157][    C7] rcu: Stack dump where RCU GP kthread last ran:
      [ 1658.929223][    C7] Sending NMI from CPU 7 to CPUs 1:
      [ 1658.929303][    C1] NMI backtrace for cpu 1
      [ 1658.929303][    C7] CPU 1 didn't respond to backtrace IPI, inspecting paca.
      [ 1658.929362][    C1] CPU: 1 PID: 325 Comm: kworker/1:1H Tainted: G        W   E     5.13.0-rc2+ #46
      [ 1658.929405][    C7] irq_soft_mask: 0x01 in_mce: 0 in_nmi: 0 current: 325 (kworker/1:1H)
      [ 1658.929465][    C1] Workqueue: events_highpri test_work_fn [test_lockup]
      [ 1658.929549][    C7] Back trace of paca->saved_r1 (0xc0000000057fb400) (possibly stale):
      [ 1658.929592][    C1] NIP:  c00000000002cf50 LR: c008000000820178 CTR: c00000000002cfa0
    
    To fix it, change the logic so that the sending CPU waits 5s for the
    receiving CPU to print its trace. If the receiving CPU prints its trace
    successfully then the sending CPU just continues, avoiding any spurious
    "stale" trace.
    
    This has the added benefit of allowing all CPUs to print their traces in
    order and avoids any interleaving of their output.
    
    Fixes: 5cc05910f26e ("powerpc/64s: Wire up arch_trigger_cpumask_backtrace()")
    Cc: stable@vger.kernel.org # v4.18+
    Reported-by: Nathan Lynch <nathanl@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20210625140408.3351173-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c2e99a8d37b90b35d7d904c86fd125375ebec2b4
Author: Yun Zhou <yun.zhou@windriver.com>
Date:   Sat Jun 26 11:21:56 2021 +0800

    seq_buf: Make trace_seq_putmem_hex() support data longer than 8
    
    commit 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 upstream.
    
    Since the raw memory 'data' does not go forward, it will dump repeated
    data if the data length is more than 8. If we want to dump longer data
    blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it
    is a bit redundant, and multiple function calls also affect the performance.
    
    Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/
    Link: https://lkml.kernel.org/r/20210626032156.47889-2-yun.zhou@windriver.com
    
    Cc: stable@vger.kernel.org
    Fixes: 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust")
    Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47ab2c74132cc926b9a6099aa985efcb721f4d00
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Tue Jun 29 09:40:10 2021 -0400

    tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing
    
    commit 9913d5745bd720c4266805c8d29952a3702e4eca upstream.
    
    All internal use cases for tracepoint_probe_register() is set to not ever
    be called with the same function and data. If it is, it is considered a
    bug, as that means the accounting of handling tracepoints is corrupted.
    If the function and data for a tracepoint is already registered when
    tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and
    return with EEXISTS.
    
    The BPF system call can end up calling tracepoint_probe_register() with
    the same data, which now means that this can trigger the warning because
    of a user space process. As WARN_ON_ONCE() should not be called because
    user space called a system call with bad data, there needs to be a way to
    register a tracepoint without triggering a warning.
    
    Enter tracepoint_probe_register_may_exist(), which can be called, but will
    not cause a WARN_ON() if the probe already exists. It will still error out
    with EEXIST, which will then be sent to the user space that performed the
    BPF system call.
    
    This keeps the previous testing for issues with other users of the
    tracepoint code, while letting BPF call it with duplicated data and not
    warn about it.
    
    Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/
    Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153
    
    Cc: stable@vger.kernel.org
    Fixes: c4f6699dfcb85 ("bpf: introduce BPF_RAW_TRACEPOINT")
    Reported-by: syzbot <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com>
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: syzbot+721aa903751db87aa244@syzkaller.appspotmail.com
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b05195282f437f7b7391837bf5afbae06ca12d0a
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Wed Jul 7 11:08:21 2021 -0400

    tracing/histograms: Fix parsing of "sym-offset" modifier
    
    commit 26c563731056c3ee66f91106c3078a8c36bb7a9e upstream.
    
    With the addition of simple mathematical operations (plus and minus), the
    parsing of the "sym-offset" modifier broke, as it took the '-' part of the
    "sym-offset" as a minus, and tried to break it up into a mathematical
    operation of "field.sym - offset", in which case it failed to parse
    (unless the event had a field called "offset").
    
    Both .sym and .sym-offset modifiers should not be entered into
    mathematical calculations anyway. If ".sym-offset" is found in the
    modifier, then simply make it not an operation that can be calculated on.
    
    Link: https://lkml.kernel.org/r/20210707110821.188ae255@oasis.local.home
    
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers")
    Reviewed-by: Tom Zanussi <zanussi@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 651c8f620e140910fb204052bb0b886bcd8a04ee
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Tue Jun 1 18:19:53 2021 +0200

    rsi: fix AP mode with WPA failure due to encrypted EAPOL
    
    commit 314538041b5632ffaf64798faaeabaf2793fe029 upstream.
    
    In AP mode WPA2-PSK connections were not established.
    
    The reason was that the AP was sending the first message
    of the 4 way handshake encrypted, even though no pairwise
    key had (correctly) yet been set.
    
    Encryption was enabled if the "security_enable" driver flag
    was set and encryption was not explicitly disabled by
    IEEE80211_TX_INTFL_DONT_ENCRYPT.
    
    However security_enable was set when *any* key, including
    the AP GTK key, had been set which was causing unwanted
    encryption even if no key was avaialble for the unicast
    packet to be sent.
    
    Fix this by adding a check that we have a key and drop
    the old security_enable driver flag which is insufficient
    and redundant.
    
    The Redpine downstream out of tree driver does it this way too.
    
    Regarding the Fixes tag the actual code being modified was
    introduced earlier, with the original driver submission, in
    dad0d04fa7ba ("rsi: Add RS9113 wireless driver"), however
    at that time AP mode was not yet supported so there was
    no bug at that point.
    
    So I have tagged the introduction of AP support instead
    which was part of the patch set "rsi: support for AP mode" [1]
    
    It is not clear whether AP WPA has ever worked, I can see nothing
    on the kernel side that broke it afterwards yet the AP support
    patch series says "Tests are performed to confirm aggregation,
    connections in WEP and WPA/WPA2 security."
    
    One possibility is that the initial tests were done with a modified
    userspace (hostapd).
    
    [1] https://www.spinics.net/lists/linux-wireless/msg165302.html
    
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    Fixes: 38ef62353acb ("rsi: security enhancements for AP mode")
    CC: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc9d17deb8008272ff71a40069f977edb0111a0c
Author: Marek Vasut <marex@denx.de>
Date:   Fri May 7 23:31:05 2021 +0200

    rsi: Assign beacon rate settings to the correct rate_info descriptor field
    
    commit b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 upstream.
    
    The RSI_RATE_x bits must be assigned to struct rsi_data_desc rate_info
    field. The rest of the driver does it correctly, except this one place,
    so fix it. This is also aligned with the RSI downstream vendor driver.
    Without this patch, an AP operating at 5 GHz does not transmit any
    beacons at all, this patch fixes that.
    
    Fixes: d26a9559403c ("rsi: add beacon changes for AP mode")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
    Cc: Angus Ainslie <angus@akkea.ca>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: Karun Eagalapati <karun256@gmail.com>
    Cc: Martin Kepplinger <martink@posteo.de>
    Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
    Cc: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
    Cc: Siva Rebbagondla <siva8118@gmail.com>
    Cc: netdev@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0036a22e5ed52cc9ff101b21db7b235b99586325
Author: Michael Buesch <m@bues.ch>
Date:   Sat May 15 21:02:52 2021 +0200

    ssb: sdio: Don't overwrite const buffer if block_write fails
    
    commit 47ec636f7a25aa2549e198c48ecb6b1c25d05456 upstream.
    
    It doesn't make sense to clobber the const driver-side buffer, if a
    write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC)
    also don't corrupt the buffer on any failure in block_write.
    Therefore, remove this memset from the SDIO variant.
    
    Signed-off-by: Michael Büsch <m@bues.ch>
    Cc: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15e84bbbea55c977db1524122d4c0272bf732f3c
Author: Pali Rohár <pali@kernel.org>
Date:   Mon May 31 17:41:27 2021 +0300

    ath9k: Fix kernel NULL pointer dereference during ath_reset_internal()
    
    commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream.
    
    I got this crash more times during debugging of PCIe controller and crash
    happens somehow at the time when PCIe kernel code started link retraining (as
    part of ASPM code) when at the same time PCIe link went down and ath9k probably
    executed hw reset procedure.
    
    Currently I'm not able to reproduce this issue as it looks like to be
    some race condition between link training, ASPM, link down and reset
    path. And as always, race conditions which depends on more input
    parameters are hard to reproduce as it depends on precise timings.
    
    But it is clear that pointers are zero in this case and should be
    properly filled as same code pattern is used in ath9k_stop() function.
    Anyway I was able to reproduce this crash by manually triggering ath
    reset worker prior putting card up. I created simple patch to export
    reset functionality via debugfs and use it to "simulate" of triggering
    reset.    s proved that NULL-pointer dereference issue is there.
    
    Function ath9k_hw_reset() is dereferencing chan structure pointer, so it
    needs to be non-NULL pointer.
    
    Function ath9k_stop() already contains code which sets ah->curchan to valid
    non-NULL pointer prior calling ath9k_hw_reset() function.
    
    Add same code pattern also into ath_reset_internal() function to prevent
    kernel NULL pointer dereference in ath9k_hw_reset() function.
    
    This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which
    is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL
    chan structure.
    
        [   45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
        [   45.344417] Mem abort info:
        [   45.347301]   ESR = 0x96000005
        [   45.350448]   EC = 0x25: DABT (current EL), IL = 32 bits
        [   45.356166]   SET = 0, FnV = 0
        [   45.359350]   EA = 0, S1PTW = 0
        [   45.362596] Data abort info:
        [   45.365756]   ISV = 0, ISS = 0x00000005
        [   45.369735]   CM = 0, WnR = 0
        [   45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000
        [   45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
        [   45.388856] Internal error: Oops: 96000005 [#1] SMP
        [   45.393897] Modules linked in: ath9k ath9k_common ath9k_hw
        [   45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785
        [   45.414746] Workqueue: phy0 ath_reset_work [ath9k]
        [   45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
        [   45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw]
        [   45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw]
        [   45.436548] sp : ffffffc0118dbca0
        [   45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000
        [   45.445442] x27: ffffff800dee4080 x26: 0000000000000000
        [   45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000
        [   45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408
        [   45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8
        [   45.467366] x19: 0000000000000000 x18: 0000000000000000
        [   45.472846] x17: 0000000000000000 x16: 0000000000000000
        [   45.478326] x15: 0000000000000010 x14: ffffffffffffffff
        [   45.483807] x13: ffffffc0918db94f x12: ffffffc011498720
        [   45.489289] x11: 0000000000000003 x10: ffffffc0114806e0
        [   45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8
        [   45.500251] x7 : c0000000ffffefff x6 : 0000000000000001
        [   45.505733] x5 : 0000000000000000 x4 : 0000000000000000
        [   45.511213] x3 : 0000000000000000 x2 : ffffff801fece870
        [   45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f
        [   45.522174] Call trace:
        [   45.524695]  ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw]
        [   45.529653]  ath_reset_internal+0x1a8/0x2b8 [ath9k]
        [   45.534696]  ath_reset_work+0x2c/0x40 [ath9k]
        [   45.539198]  process_one_work+0x210/0x480
        [   45.543339]  worker_thread+0x5c/0x510
        [   45.547115]  kthread+0x12c/0x130
        [   45.550445]  ret_from_fork+0x10/0x1c
        [   45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61)
        [   45.560430] ---[ end trace 566410ba90b50e8b ]---
        [   45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt
        [   45.572282] SMP: stopping secondary CPUs
        [   45.576331] Kernel Offset: disabled
        [   45.579924] CPU features: 0x00040002,0000200c
        [   45.584416] Memory Limit: none
        [   45.587564] Rebooting in 3 seconds..
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3343d0192ed7cce9744ab973400f0a12916f466c
Author: Ondrej Zary <linux@zary.sk>
Date:   Fri Jun 11 22:19:39 2021 +0200

    serial_cs: remove wrong GLOBETROTTER.cis entry
    
    commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream.
    
    The GLOBETROTTER.cis entry in serial_cs matches more devices than
    intended and breaks them. Remove it.
    
    Example: # pccardctl info
    PRODID_1="Option International
    "
    PRODID_2="GSM-Ready 56K/ISDN
    "
    PRODID_3="021
    "
    PRODID_4="A
    "
    MANFID=0013,0000
    FUNCID=0
    
    result:
    pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2
    
    The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at
    https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41
    It's from completely diffetent card:
    vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A"
    
    Signed-off-by: Ondrej Zary <linux@zary.sk>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3474a9b57b67349977f31ff355f35863ed742010
Author: Ondrej Zary <linux@zary.sk>
Date:   Fri Jun 11 22:19:40 2021 +0200

    serial_cs: Add Option International GSM-Ready 56K/ISDN modem
    
    commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream.
    
    Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem
    card.
    
    Signed-off-by: Ondrej Zary <linux@zary.sk>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06e64e9b9d9394cdbafbd269473cc2371e27a8f8
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Thu Jun 10 20:08:06 2021 +0900

    serial: sh-sci: Stop dmaengine transfer in sci_stop_tx()
    
    commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream.
    
    Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following
    message is possible output when system enters suspend and while
    transferring data, because clearing TIE bit in SCSCR is not able to
    stop any dmaengine transfer.
    
        sh-sci e6550000.serial: ttySC1: Unable to drain transmitter
    
    Note that this driver has already used some #ifdef in the .c file
    so that this patch also uses #ifdef to fix the issue. Otherwise,
    build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled.
    
    Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
    Cc: <stable@vger.kernel.org> # v4.9+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 59ea111143ec1591e746d37e9d8d0727f04516b2
Author: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Date:   Thu Jun 10 15:46:18 2021 +0200

    iio: ltr501: ltr501_read_ps(): add missing endianness conversion
    
    commit 71b33f6f93ef9462c84560e2236ed22209d26a58 upstream.
    
    The PS ADC Channel data is spread over 2 registers in little-endian
    form. This patch adds the missing endianness conversion.
    
    Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
    Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
    Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 049fb271acf9816a19e3ed4bb0785d9876a6f702
Author: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
Date:   Thu Jun 10 15:46:17 2021 +0200

    iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR
    
    commit 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 upstream.
    
    The ltr559 chip uses only the lowest bit of the ALS_CONTR register to
    configure between active and stand-by mode. In the original driver
    BIT(1) is used, which does a software reset instead.
    
    This patch fixes the problem by using BIT(0) as als_mode_active for
    the ltr559 chip.
    
    Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip")
    Signed-off-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
    Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 56161cf5c3c982351a5f2b27cc97b3f7e339562f
Author: Marc Kleine-Budde <mkl@pengutronix.de>
Date:   Thu Jun 10 15:46:16 2021 +0200

    iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too
    
    commit 2ac0b029a04b673ce83b5089368f467c5dca720c upstream.
    
    The regmap is configured for 8 bit registers, uses a RB-Tree cache and
    marks several registers as volatile (i.e. do not cache).
    
    The ALS and PS data registers in the chip are 16 bit wide and spans
    two regmap registers. In the current driver only the base register is
    marked as volatile, resulting in the upper register only read once.
    
    Further the data sheet notes:
    
    | When the I2C read operation starts, all four ALS data registers are
    | locked until the I2C read operation of register 0x8B is completed.
    
    Which results in the registers never update after the 2nd read.
    
    This patch fixes the problem by marking the upper 8 bits of the ALS
    and PS registers as volatile, too.
    
    Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.")
    Reported-by: Oliver Lang <Oliver.Lang@gossenmetrawatt.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Tested-by: Nikita Travkin <nikita@trvn.ru> # ltr559
    Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e2326cefd2ed110a43a0903cfaa99333512cf420
Author: frank zago <frank@zago.net>
Date:   Mon Apr 26 21:20:17 2021 -0500

    iio: light: tcs3472: do not free unallocated IRQ
    
    commit 7cd04c863f9e1655d607705455e7714f24451984 upstream.
    
    Allocating an IRQ is conditional to the IRQ existence, but freeing it
    was not. If no IRQ was allocate, the driver would still try to free
    IRQ 0. Add the missing checks.
    
    This fixes the following trace when the driver is removed:
    
    [  100.667788] Trying to free already-free IRQ 0
    [  100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370
    ...
    [  100.667914] Call Trace:
    [  100.667920]  tcs3472_remove+0x3a/0x90 [tcs3472]
    [  100.667927]  i2c_device_remove+0x2b/0xa0
    
    Signed-off-by: frank zago <frank@zago.net>
    Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net
    Fixes: 9d2f715d592e ("iio: light: tcs3472: support out-of-threshold events")
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3f1aab2fa0c20a209618c2c6187d2362e828f3fc
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Mon Jun 7 19:36:40 2021 +0200

    rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path
    
    commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream.
    
    The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck.
    
    If clk_prepare_enable() fails for the second clock (rtc_ck) we must only
    call clk_disable_unprepare() for the first clock (pclk) but currently we
    call it on both leading to a WARN:
    
    [   15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8
    [   15.637620] ck_rtc already disabled
    [   15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413
    [   15.674510] Hardware name: STM32 (Device Tree Support)
    [   15.679658] [<c0111148>] (unwind_backtrace) from [<c010c0b8>] (show_stack+0x10/0x14)
    [   15.687371] [<c010c0b8>] (show_stack) from [<c0ab3d28>] (dump_stack+0xc0/0xe0)
    [   15.694574] [<c0ab3d28>] (dump_stack) from [<c012360c>] (__warn+0xc8/0xf0)
    [   15.701428] [<c012360c>] (__warn) from [<c0123694>] (warn_slowpath_fmt+0x60/0x94)
    [   15.708894] [<c0123694>] (warn_slowpath_fmt) from [<c053b518>] (clk_core_disable+0xb0/0xc8)
    [   15.717230] [<c053b518>] (clk_core_disable) from [<c053c190>] (clk_core_disable_lock+0x18/0x24)
    [   15.725924] [<c053c190>] (clk_core_disable_lock) from [<bf0adc44>] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32])
    [   15.735739] [<bf0adc44>] (stm32_rtc_probe [rtc_stm32]) from [<c05f7d4c>] (platform_drv_probe+0x48/0x98)
    [   15.745095] [<c05f7d4c>] (platform_drv_probe) from [<c05f5cec>] (really_probe+0x1f0/0x458)
    [   15.753338] [<c05f5cec>] (really_probe) from [<c05f61c4>] (driver_probe_device+0x70/0x1c4)
    [   15.761584] [<c05f61c4>] (driver_probe_device) from [<c05f6580>] (device_driver_attach+0x58/0x60)
    [   15.770439] [<c05f6580>] (device_driver_attach) from [<c05f6654>] (__driver_attach+0xcc/0x170)
    [   15.779032] [<c05f6654>] (__driver_attach) from [<c05f40d8>] (bus_for_each_dev+0x58/0x7c)
    [   15.787191] [<c05f40d8>] (bus_for_each_dev) from [<c05f4ffc>] (bus_add_driver+0xdc/0x1f8)
    [   15.795352] [<c05f4ffc>] (bus_add_driver) from [<c05f6ed8>] (driver_register+0x7c/0x110)
    [   15.803425] [<c05f6ed8>] (driver_register) from [<c01027bc>] (do_one_initcall+0x70/0x1b8)
    [   15.811588] [<c01027bc>] (do_one_initcall) from [<c01a1094>] (do_init_module+0x58/0x1f8)
    [   15.819660] [<c01a1094>] (do_init_module) from [<c01a0074>] (load_module+0x1e58/0x23c8)
    [   15.827646] [<c01a0074>] (load_module) from [<c01a0860>] (sys_finit_module+0xa0/0xd4)
    [   15.835459] [<c01a0860>] (sys_finit_module) from [<c01011e0>] (__sys_trace_return+0x0/0x20)
    
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
    Cc: stable@vger.kernel.org
    Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 050b80f9d3fddd3688be3c16c4f94397ae795826
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date:   Wed Jun 9 09:21:08 2021 +0200

    s390/cio: dont call css_wait_for_slow_path() inside a lock
    
    commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream.
    
    Currently css_wait_for_slow_path() gets called inside the chp->lock.
    The path-verification-loop of slowpath inside this lock could lead to
    deadlock as reported by the lockdep validator.
    
    The ccw_device_get_chp_desc() during the instance of a device-set-online
    would try to acquire the same 'chp->lock' to read the chp->desc.
    The instance of this function can get called from multiple scenario,
    like probing or setting-device online manually. This could, in some
    corner-cases lead to the deadlock.
    
    lockdep validator reported this as,
    
            CPU0                    CPU1
            ----                    ----
       lock(&chp->lock);
                                    lock(kn->active#43);
                                    lock(&chp->lock);
       lock((wq_completion)cio);
    
    The chp->lock was introduced to serialize the access of struct
    channel_path. This lock is not needed for the css_wait_for_slow_path()
    function, so invoke the slow-path function outside this lock.
    
    Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba124fdcd12bf471b6974fb3662e80c168634c93
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Sat Jun 26 15:50:42 2021 +0800

    SUNRPC: Should wake up the privileged task firstly.
    
    commit 5483b904bf336948826594610af4c9bbb0d9e3aa upstream.
    
    When find a task from wait queue to wake up, a non-privileged task may
    be found out, rather than the privileged. This maybe lead a deadlock
    same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode()
    and nfs4_opendata_get_inode()"):
    
    Privileged delegreturn task is queued to privileged list because all
    the slots are assigned. If there has no enough slot to wake up the
    non-privileged batch tasks(session less than 8 slot), then the privileged
    delegreturn task maybe lost waked up because the found out task can't
    get slot since the session is on draining.
    
    So we should treate the privileged task as the emergency task, and
    execute it as for as we can.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acc7947439436ce78d37c906d9f27d2d886d4308
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Sat Jun 26 15:50:41 2021 +0800

    SUNRPC: Fix the batch tasks count wraparound.
    
    commit fcb170a9d825d7db4a3fb870b0300f5a40a8d096 upstream.
    
    The 'queue->nr' will wraparound from 0 to 255 when only current
    priority queue has tasks. This maybe lead a deadlock same as commit
    dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode()
    and nfs4_opendata_get_inode()"):
    
    Privileged delegreturn task is queued to privileged list because all
    the slots are assigned. When non-privileged task complete and release
    the slot, a non-privileged maybe picked out. It maybe allocate slot
    failed when the session on draining.
    
    If the 'queue->nr' has wraparound to 255, and no enough slot to
    service it, then the privileged delegreturn will lost to wake up.
    
    So we should avoid the wraparound on 'queue->nr'.
    
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c38e5045af01dfe6a244b3d042aa7d38b0db2f6e
Author: Stephane Grosjean <s.grosjean@peak-system.com>
Date:   Wed Jun 23 16:26:00 2021 +0200

    can: peak_pciefd: pucan_handle_status(): fix a potential starvation issue in TX path
    
    commit b17233d385d0b6b43ecf81d43008cb1bbb008166 upstream.
    
    Rather than just indicating that transmission can start, this patch
    requires the explicit flushing of the network TX queue when the driver
    is informed by the device that it can transmit, next to its
    configuration.
    
    In this way, if frames have already been written by the application,
    they will actually be transmitted.
    
    Fixes: ffd137f7043c ("can: peak/pcie_fd: remove useless code when interface starts")
    Link: https://lore.kernel.org/r/20210623142600.149904-1-s.grosjean@peak-system.com
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ca519986d38096597556b03674f8c75ff859669
Author: Oliver Hartkopp <socketcan@hartkopp.net>
Date:   Fri Jun 18 19:36:45 2021 +0200

    can: gw: synchronize rcu operations before removing gw job entry
    
    commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream.
    
    can_can_gw_rcv() is called under RCU protection, so after calling
    can_rx_unregister(), we have to call synchronize_rcu in order to wait
    for any RCU read-side critical sections to finish before removing the
    kmem_cache entry with the referenced gw job entry.
    
    Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net
    Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing")
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eabe65197876e4a0906eab784f5766c4c76098c7
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Sat Jun 19 13:18:13 2021 -0300

    can: bcm: delay release of struct bcm_op after synchronize_rcu()
    
    commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463 upstream.
    
    can_rx_register() callbacks may be called concurrently to the call to
    can_rx_unregister(). The callbacks and callback data, though, are
    protected by RCU and the struct sock reference count.
    
    So the callback data is really attached to the life of sk, meaning
    that it should be released on sk_destruct. However, bcm_remove_op()
    calls tasklet_kill(), and RCU callbacks may be called under RCU
    softirq, so that cannot be used on kernels before the introduction of
    HRTIMER_MODE_SOFT.
    
    However, bcm_rx_handler() is called under RCU protection, so after
    calling can_rx_unregister(), we may call synchronize_rcu() in order to
    wait for any RCU read-side critical sections to finish. That is,
    bcm_rx_handler() won't be called anymore for those ops. So, we only
    free them, after we do that synchronize_rcu().
    
    Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol")
    Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com
    Cc: linux-stable <stable@vger.kernel.org>
    Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com
    Reported-by: Norbert Slusarek <nslusarek@gmx.net>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80f566c013ba357bc6e14fc2c55d2793e494d07c
Author: Stephen Brennan <stephen.s.brennan@oracle.com>
Date:   Wed Jun 23 16:21:14 2021 -0700

    ext4: use ext4_grp_locked_error in mb_find_extent
    
    commit cd84bbbac12a173a381a64c6ec8b76a5277b87b5 upstream.
    
    Commit 5d1b1b3f492f ("ext4: fix BUG when calling ext4_error with locked
    block group") introduces ext4_grp_locked_error to handle unlocking a
    group in error cases. Otherwise, there is a possibility of a sleep while
    atomic. However, since 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON
    in mb_find_extent()"), mb_find_extent() has contained a ext4_error()
    call while a group spinlock is held. Replace this with
    ext4_grp_locked_error.
    
    Fixes: 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()")
    Cc: <stable@vger.kernel.org> # 4.14+
    Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
    Reviewed-by: Lukas Czerner <lczerner@redhat.com>
    Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
    Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fdb1e064f2cc38f99e4ccf6890f03b1ae3c52729
Author: Pan Dong <pandong.peter@bytedance.com>
Date:   Tue May 25 15:36:56 2021 +0800

    ext4: fix avefreec in find_group_orlov
    
    commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream.
    
    The avefreec should be average free clusters instead
    of average free blocks, otherwize Orlov's allocator
    will not work properly when bigalloc enabled.
    
    Cc: stable@kernel.org
    Signed-off-by: Pan Dong <pandong.peter@bytedance.com>
    Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc0458bcd213f544edefe8b38d6ef23eedd568ee
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat May 22 18:30:44 2021 +0800

    ext4: remove check for zero nr_to_scan in ext4_es_scan()
    
    commit e5e7010e5444d923e4091cafff61d05f2d19cada upstream.
    
    After converting fs shrinkers to new scan/count API, we are no longer
    pass zero nr_to_scan parameter to detect the number of objects to free,
    just remove this check.
    
    Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API")
    Cc: stable@vger.kernel.org # 3.12+
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2338dc5d32636d26d6a99e022ca0cb1dc6e37741
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Sat May 22 18:30:45 2021 +0800

    ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit
    
    commit 4fb7c70a889ead2e91e184895ac6e5354b759135 upstream.
    
    The cache_cnt parameter of tracepoint ext4_es_shrink_exit means the
    remaining cache count after shrink, but now it is the cache count before
    shrink, fix it by read sbi->s_extent_cache_cnt again.
    
    Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API")
    Cc: stable@vger.kernel.org # 3.12+
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5485fe228f9771190de24f8936c43879fa52fc25
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon May 10 19:10:51 2021 +0800

    ext4: return error code when ext4_fill_flex_info() fails
    
    commit 8f6840c4fd1e7bd715e403074fb161c1a04cda73 upstream.
    
    After commit c89128a00838 ("ext4: handle errors on
    ext4_commit_super"), 'ret' may be set to 0 before calling
    ext4_fill_flex_info(), if ext4_fill_flex_info() fails ext4_mount()
    doesn't return error code, it makes 'root' is null which causes crash
    in legacy_get_tree().
    
    Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super")
    Reported-by: Hulk Robot <hulkci@huawei.com>
    Cc: <stable@vger.kernel.org> # v4.18+
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20210510111051.55650-1-yangyingliang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9ed3a3d3a8d2cbe99d9e4386a98856491f0eade0
Author: Anirudh Rayabharam <mail@anirudhrb.com>
Date:   Fri May 7 00:26:54 2021 +0530

    ext4: fix kernel infoleak via ext4_extent_header
    
    commit ce3aba43599f0b50adbebff133df8d08a3d5fffe upstream.
    
    Initialize eh_generation of struct ext4_extent_header to prevent leaking
    info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at:
    http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8
    
    Cc: stable@kernel.org
    Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com
    Fixes: a86c61812637 ("[PATCH] ext3: add extent map support")
    Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com>
    Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97df16a8fa4d19849a2b0cad0241dfdfc0acea4e
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri May 7 15:19:04 2021 +0800

    ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle
    
    commit b9a037b7f3c401d3c63e0423e56aef606b1ffaaf upstream.
    
    In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction
    handle, it didn't remove the inode from the in-core orphan list, which
    may probably trigger below error dump in ext4_destroy_inode() during the
    final iput() and could lead to memory corruption on the later orphan
    list changes.
    
     EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed!
     00000000b8247c67: 0001f30a 00000004 00000000 00000023  ............#...
     00000000e24cde71: 00000006 014082a3 00000000 00000000  ......@.........
     0000000072c6a5ee: 00000000 00000000 00000000 00000000  ................
     ...
    
    This patch fix this by cleanup in-core orphan list manually if
    ext4_truncate() return error.
    
    Cc: stable@kernel.org
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e00c01b74add2dfa6947c1cefc74760e560dbf55
Author: David Sterba <dsterba@suse.com>
Date:   Tue Jul 7 18:30:06 2020 +0200

    btrfs: clear defrag status of a root if starting transaction fails
    
    commit 6819703f5a365c95488b07066a8744841bf14231 upstream.
    
    The defrag loop processes leaves in batches and starting transaction for
    each. The whole defragmentation on a given root is protected by a bit
    but in case the transaction fails, the bit is not cleared
    
    In case the transaction fails the bit would prevent starting
    defragmentation again, so make sure it's cleared.
    
    CC: stable@vger.kernel.org # 4.4+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce3986380a1084e78f0831610b8d587d57642e43
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Jun 9 11:25:03 2021 +0100

    btrfs: send: fix invalid path for unlink operations after parent orphanization
    
    commit d8ac76cdd1755b21e8c008c28d0b7251c0b14986 upstream.
    
    During an incremental send operation, when processing the new references
    for the current inode, we might send an unlink operation for another inode
    that has a conflicting path and has more than one hard link. However this
    path was computed and cached before we processed previous new references
    for the current inode. We may have orphanized a directory of that path
    while processing a previous new reference, in which case the path will
    be invalid and cause the receiver process to fail.
    
    The following reproducer triggers the problem and explains how/why it
    happens in its comments:
    
      $ cat test-send-unlink.sh
      #!/bin/bash
    
      DEV=/dev/sdi
      MNT=/mnt/sdi
    
      mkfs.btrfs -f $DEV >/dev/null
      mount $DEV $MNT
    
      # Create our test files and directory. Inode 259 (file3) has two hard
      # links.
      touch $MNT/file1
      touch $MNT/file2
      touch $MNT/file3
    
      mkdir $MNT/A
      ln $MNT/file3 $MNT/A/hard_link
    
      # Filesystem looks like:
      #
      # .                                     (ino 256)
      # |----- file1                          (ino 257)
      # |----- file2                          (ino 258)
      # |----- file3                          (ino 259)
      # |----- A/                             (ino 260)
      #        |---- hard_link                (ino 259)
      #
    
      # Now create the base snapshot, which is going to be the parent snapshot
      # for a later incremental send.
      btrfs subvolume snapshot -r $MNT $MNT/snap1
      btrfs send -f /tmp/snap1.send $MNT/snap1
    
      # Move inode 257 into directory inode 260. This results in computing the
      # path for inode 260 as "/A" and caching it.
      mv $MNT/file1 $MNT/A/file1
    
      # Move inode 258 (file2) into directory inode 260, with a name of
      # "hard_link", moving first inode 259 away since it currently has that
      # location and name.
      mv $MNT/A/hard_link $MNT/tmp
      mv $MNT/file2 $MNT/A/hard_link
    
      # Now rename inode 260 to something else (B for example) and then create
      # a hard link for inode 258 that has the old name and location of inode
      # 260 ("/A").
      mv $MNT/A $MNT/B
      ln $MNT/B/hard_link $MNT/A
    
      # Filesystem now looks like:
      #
      # .                                     (ino 256)
      # |----- tmp                            (ino 259)
      # |----- file3                          (ino 259)
      # |----- B/                             (ino 260)
      # |      |---- file1                    (ino 257)
      # |      |---- hard_link                (ino 258)
      # |
      # |----- A                              (ino 258)
    
      # Create another snapshot of our subvolume and use it for an incremental
      # send.
      btrfs subvolume snapshot -r $MNT $MNT/snap2
      btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2
    
      # Now unmount the filesystem, create a new one, mount it and try to
      # apply both send streams to recreate both snapshots.
      umount $DEV
    
      mkfs.btrfs -f $DEV >/dev/null
    
      mount $DEV $MNT
    
      # First add the first snapshot to the new filesystem by applying the
      # first send stream.
      btrfs receive -f /tmp/snap1.send $MNT
    
      # The incremental receive operation below used to fail with the
      # following error:
      #
      #    ERROR: unlink A/hard_link failed: No such file or directory
      #
      # This is because when send is processing inode 257, it generates the
      # path for inode 260 as "/A", since that inode is its parent in the send
      # snapshot, and caches that path.
      #
      # Later when processing inode 258, it first processes its new reference
      # that has the path of "/A", which results in orphanizing inode 260
      # because there is a a path collision. This results in issuing a rename
      # operation from "/A" to "/o260-6-0".
      #
      # Finally when processing the new reference "B/hard_link" for inode 258,
      # it notices that it collides with inode 259 (not yet processed, because
      # it has a higher inode number), since that inode has the name
      # "hard_link" under the directory inode 260. It also checks that inode
      # 259 has two hardlinks, so it decides to issue a unlink operation for
      # the name "hard_link" for inode 259. However the path passed to the
      # unlink operation is "/A/hard_link", which is incorrect since currently
      # "/A" does not exists, due to the orphanization of inode 260 mentioned
      # before. The path is incorrect because it was computed and cached
      # before the orphanization. This results in the receiver to fail with
      # the above error.
      btrfs receive -f /tmp/snap2.send $MNT
    
      umount $MNT
    
    When running the test, it fails like this:
    
      $ ./test-send-unlink.sh
      Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1'
      At subvol /mnt/sdi/snap1
      Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2'
      At subvol /mnt/sdi/snap2
      At subvol snap1
      At snapshot snap2
      ERROR: unlink A/hard_link failed: No such file or directory
    
    Fix this by recomputing a path before issuing an unlink operation when
    processing the new references for the current inode if we previously
    have orphanized a directory.
    
    A test case for fstests will follow soon.
    
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe0c1aa932321556442e1647f617170ff03e48e9
Author: Ludovic Desroches <ludovic.desroches@microchip.com>
Date:   Fri Oct 25 10:42:10 2019 +0200

    ARM: dts: at91: sama5d4: fix pinctrl muxing
    
    commit 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c upstream.
    
    Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It
    allows to use SCK0, SCK1 and SPI0_NPCS2 signals.
    
    Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
    Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD")
    Cc: stable@vger.kernel.org # v4.4+
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 90639a0e19a916de955bdab3c56d7eda668b32ae
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Fri Apr 30 09:26:59 2021 +0800

    arm_pmu: Fix write counter incorrect in ARMv7 big-endian mode
    
    commit fdbef8c4e68ad423416aa6cc93d1616d6f8ac5b3 upstream.
    
    Commit 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values")
    changes the input "value" type from 32-bit to 64-bit, which introduces the
    following problem: ARMv7 PMU counters is 32-bit width, in big-endian mode,
    write counter uses high 32-bit, which writes an incorrect value.
    
    Before:
    
     Performance counter stats for 'ls':
    
                  2.22 msec task-clock                #    0.675 CPUs utilized
                     0      context-switches          #    0.000 K/sec
                     0      cpu-migrations            #    0.000 K/sec
                    49      page-faults               #    0.022 M/sec
            2150476593      cycles                    #  966.663 GHz
            2148588788      instructions              #    1.00  insn per cycle
            2147745484      branches                  # 965435.074 M/sec
            2147508540      branch-misses             #   99.99% of all branches
    
    None of the above hw event counters are correct.
    
    Solution:
    
    "value" forcibly converted to 32-bit type before being written to PMU register.
    
    After:
    
     Performance counter stats for 'ls':
    
                  2.09 msec task-clock                #    0.681 CPUs utilized
                     0      context-switches          #    0.000 K/sec
                     0      cpu-migrations            #    0.000 K/sec
                    46      page-faults               #    0.022 M/sec
               2807301      cycles                    #    1.344 GHz
               1060159      instructions              #    0.38  insn per cycle
                250496      branches                  #  119.914 M/sec
                 23192      branch-misses             #    9.26% of all branches
    
    Fixes: 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20210430012659.232110-1-yangjihong1@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b62ce8e3f7fbd81ea7c9341ac5e0d445f685f6af
Author: Alexander Larkin <avlarkin82@gmail.com>
Date:   Sun Jul 4 22:39:36 2021 -0700

    Input: joydev - prevent use of not validated data in JSIOCSBTNMAP ioctl
    
    commit f8f84af5da9ee04ef1d271528656dac42a090d00 upstream.
    
    Even though we validate user-provided inputs we then traverse past
    validated data when applying the new map. The issue was originally
    discovered by Murray McAllister with this simple POC (if the following
    is executed by an unprivileged user it will instantly panic the system):
    
    int main(void) {
            int fd, ret;
            unsigned int buffer[10000];
    
            fd = open("/dev/input/js0", O_RDONLY);
            if (fd == -1)
                    printf("Error opening file\n");
    
            ret = ioctl(fd, JSIOCSBTNMAP & ~IOCSIZE_MASK, &buffer);
            printf("%d\n", ret);
    }
    
    The solution is to traverse internal buffer which is guaranteed to only
    contain valid date when constructing the map.
    
    Fixes: 182d679b2298 ("Input: joydev - prevent potential read overflow in ioctl")
    Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones")
    Reported-by: Murray McAllister <murray.mcallister@gmail.com>
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Alexander Larkin <avlarkin82@gmail.com>
    Link: https://lore.kernel.org/r/20210620120030.1513655-1-avlarkin82@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit faf8ab4355ec527f7fd1a4bab8c66f596c8490a8
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Wed Jun 2 14:48:21 2021 -0400

    iov_iter_fault_in_readable() should do nothing in xarray case
    
    commit 0e8f0d67401589a141950856902c7d0ec8d9c985 upstream.
    
    ... and actually should just check it's given an iovec-backed iterator
    in the first place.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00f00f5db888e9f8dfaaa2e6b8d6cf5a6c28753b
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date:   Mon Jun 28 19:33:52 2021 -0700

    ntfs: fix validity check for file name attribute
    
    commit d98e4d95411bbde2220a7afa38dcc9c14d71acbe upstream.
    
    When checking the file name attribute, we want to ensure that it fits
    within the bounds of ATTR_RECORD.  To do this, we should check that (attr
    record + file name offset + file name length) < (attr record + attr record
    length).
    
    However, the original check did not include the file name offset in the
    calculation.  This means that corrupted on-disk metadata might not caught
    by the incorrect file name check, and lead to an invalid memory access.
    
    An example can be seen in the crash report of a memory corruption error
    found by Syzbot:
    https://syzkaller.appspot.com/bug?id=a1a1e379b225812688566745c3e2f7242bffc246
    
    Adding the file name offset to the validity check fixes this error and
    passes the Syzbot reproducer test.
    
    Link: https://lkml.kernel.org/r/20210614050540.289494-1-desmondcheongzx@gmail.com
    Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
    Reported-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
    Tested-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
    Acked-by: Anton Altaparmakov <anton@tuxera.com>
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f26f2e79dcc8b2698960cf73f38bf100c250ba8
Author: Zhangjiantao (Kirin, nanjing) <water.zhangjiantao@huawei.com>
Date:   Thu Jun 17 18:03:54 2021 +0300

    xhci: solve a double free problem while doing s4
    
    commit b31d9d6d7abbf6483b871b6370bc31c930d53f54 upstream.
    
    when system is doing s4, the process of xhci_resume may be as below:
    1、xhci_mem_cleanup
    2、xhci_init->xhci_mem_init->xhci_mem_cleanup(when memory is not enough).
    xhci_mem_cleanup will be executed twice when system is out of memory.
    xhci->port_caps is freed in xhci_mem_cleanup,but it isn't set to NULL.
    It will be freed twice when xhci_mem_cleanup is called the second time.
    
    We got following bug when system resumes from s4:
    
    kernel BUG at mm/slub.c:309!
    Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    CPU: 0 PID: 5929 Tainted: G S   W   5.4.96-arm64-desktop #1
    pc : __slab_free+0x5c/0x424
    lr : kfree+0x30c/0x32c
    
    Call trace:
     __slab_free+0x5c/0x424
     kfree+0x30c/0x32c
     xhci_mem_cleanup+0x394/0x3cc
     xhci_mem_init+0x9ac/0x1070
     xhci_init+0x8c/0x1d0
     xhci_resume+0x1cc/0x5fc
     xhci_plat_resume+0x64/0x70
     platform_pm_thaw+0x28/0x60
     dpm_run_callback+0x54/0x24c
     device_resume+0xd0/0x200
     async_resume+0x24/0x60
     async_run_entry_fn+0x44/0x110
     process_one_work+0x1f0/0x490
     worker_thread+0x5c/0x450
     kthread+0x158/0x160
     ret_from_fork+0x10/0x24
    
    Original patch that caused this issue was backported to 4.4 stable,
    so this should be backported to 4.4 stabe as well.
    
    Fixes: cf0ee7c60c89 ("xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2")
    Cc: stable@vger.kernel.org # v4.4+
    Signed-off-by: Jiantao Zhang <water.zhangjiantao@huawei.com>
    Signed-off-by: Tao Xue <xuetao09@huawei.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20210617150354.1512157-5-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c7de678190ac6d48e51633584075d045901b580
Author: Jing Xiangfeng <jingxiangfeng@huawei.com>
Date:   Thu Jun 17 15:32:26 2021 +0800

    usb: typec: Add the missed altmode_id_remove() in typec_register_altmode()
    
    commit 03026197bb657d784220b040c6173267a0375741 upstream.
    
    typec_register_altmode() misses to call altmode_id_remove() in an error
    path. Add the missed function call to fix it.
    
    Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
    Cc: stable <stable@vger.kernel.org>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
    Link: https://lore.kernel.org/r/20210617073226.47599-1-jingxiangfeng@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 309970bf56ed469eef1d59d20be5d37693845076
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Thu Jun 17 09:55:24 2021 -0700

    usb: dwc3: Fix debugfs creation flow
    
    commit 84524d1232ecca7cf8678e851b254f05cff4040a upstream.
    
    Creation EP's debugfs called earlier than debugfs folder for dwc3
    device created. As result EP's debugfs are created in '/sys/kernel/debug'
    instead of '/sys/kernel/debug/usb/dwc3.1.auto'.
    
    Moved dwc3_debugfs_init() function call before calling
    dwc3_core_init_mode() to allow create dwc3 debugfs parent before
    creating EP's debugfs's.
    
    Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically")
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Jack Pham <jackp@codeaurora.org>
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/01fafb5b2d8335e98e6eadbac61fc796bdf3ec1a.1623948457.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c984eaeb01ce7c15d757b214ab90a7aabe4a72a8
Author: Hannu Hartikainen <hannu@hrtk.in>
Date:   Tue Jun 22 17:14:54 2021 +0300

    USB: cdc-acm: blacklist Heimann USB Appset device
    
    commit 4897807753e078655a78de39ed76044d784f3e63 upstream.
    
    The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be
    a CDC-ACM device in its descriptors but in fact is not. If it is run
    with echo disabled it returns garbled data, probably due to something
    that happens in the TTY layer. And when run with echo enabled (the
    default), it will mess up the calibration data of the sensor the first
    time any data is sent to the device.
    
    In short, I had a bad time after connecting the sensor and trying to get
    it to work. I hope blacklisting it in the cdc-acm driver will save
    someone else a bit of trouble.
    
    Signed-off-by: Hannu Hartikainen <hannu@hrtk.in>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d654be97e1b679616e3337b871a9ec8f31a88841
Author: Linyu Yuan <linyyuan@codeaurora.com>
Date:   Wed Jun 16 19:51:42 2021 +0800

    usb: gadget: eem: fix echo command packet response issue
    
    commit 4249d6fbc10fd997abdf8a1ea49c0389a0edf706 upstream.
    
    when receive eem echo command, it will send a response,
    but queue this response to the usb request which allocate
    from gadget device endpoint zero,
    and transmit the request to IN endpoint of eem interface.
    
    on dwc3 gadget, it will trigger following warning in function
    __dwc3_gadget_ep_queue(),
    
            if (WARN(req->dep != dep, "request %pK belongs to '%s'\n",
                                    &req->request, req->dep->name))
                    return -EINVAL;
    
    fix it by allocating a usb request from IN endpoint of eem interface,
    and transmit the usb request to same IN endpoint of eem interface.
    
    Signed-off-by: Linyu Yuan <linyyuan@codeaurora.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210616115142.34075-1-linyyuan@codeaurora.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16151f468e8a7122bca0ee92732bd9ed09735f49
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Thu Jun 17 21:51:30 2021 +0300

    net: can: ems_usb: fix use-after-free in ems_usb_disconnect()
    
    commit ab4a0b8fcb9a95c02909b62049811bd2e586aaa4 upstream.
    
    In ems_usb_disconnect() dev pointer, which is netdev private data, is
    used after free_candev() call:
    |       if (dev) {
    |               unregister_netdev(dev->netdev);
    |               free_candev(dev->netdev);
    |
    |               unlink_all_urbs(dev);
    |
    |               usb_free_urb(dev->intr_urb);
    |
    |               kfree(dev->intr_in_buffer);
    |               kfree(dev->tx_msg_buffer);
    |       }
    
    Fix it by simply moving free_candev() at the end of the block.
    
    Fail log:
    | BUG: KASAN: use-after-free in ems_usb_disconnect
    | Read of size 8 at addr ffff88804e041008 by task kworker/1:2/2895
    |
    | CPU: 1 PID: 2895 Comm: kworker/1:2 Not tainted 5.13.0-rc5+ #164
    | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.4
    | Workqueue: usb_hub_wq hub_event
    | Call Trace:
    |     dump_stack (lib/dump_stack.c:122)
    |     print_address_description.constprop.0.cold (mm/kasan/report.c:234)
    |     kasan_report.cold (mm/kasan/report.c:420 mm/kasan/report.c:436)
    |     ems_usb_disconnect (drivers/net/can/usb/ems_usb.c:683 drivers/net/can/usb/ems_usb.c:1058)
    
    Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface")
    Link: https://lore.kernel.org/r/20210617185130.5834-1-paskripkin@gmail.com
    Cc: linux-stable <stable@vger.kernel.org>
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bfa8fce9c16596643939bacdf72fa6a4dc84a706
Author: Johan Hovold <johan@kernel.org>
Date:   Mon May 24 10:02:59 2021 -0700

    Input: usbtouchscreen - fix control-request directions
    
    commit 41e81022a04a0294c55cfa7e366bc14b9634c66e upstream.
    
    The direction of the pipe argument must match the request-type direction
    bit or control requests may fail depending on the host-controller-driver
    implementation.
    
    Fix the four control requests which erroneously used usb_rcvctrlpipe().
    
    Fixes: 1d3e20236d7a ("[PATCH] USB: usbtouchscreen: unified USB touchscreen driver")
    Fixes: 24ced062a296 ("usbtouchscreen: add support for DMC TSC-10/25 devices")
    Fixes: 9e3b25837a20 ("Input: usbtouchscreen - add support for e2i touchscreen controller")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Cc: stable@vger.kernel.org      # 2.6.17
    Link: https://lore.kernel.org/r/20210524092048.4443-1-johan@kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b39d5fee82017382474834bba6999dfd73944bb3
Author: Pavel Skripkin <paskripkin@gmail.com>
Date:   Fri May 7 14:50:43 2021 +0200

    media: dvb-usb: fix wrong definition
    
    commit c680ed46e418e9c785d76cf44eb33bfd1e8cf3f6 upstream.
    
    syzbot reported WARNING in vmalloc. The problem
    was in zero size passed to vmalloc.
    
    The root case was in wrong cxusb_bluebird_lgz201_properties
    definition. adapter array has only 1 entry, but num_adapters was
    2.
    
    Call Trace:
     __vmalloc_node mm/vmalloc.c:2963 [inline]
     vmalloc+0x67/0x80 mm/vmalloc.c:2996
     dvb_dmx_init+0xe4/0xb90 drivers/media/dvb-core/dvb_demux.c:1251
     dvb_usb_adapter_dvb_init+0x564/0x860 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:184
     dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86 [inline]
     dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline]
     dvb_usb_device_init.cold+0xc94/0x146e drivers/media/usb/dvb-usb/dvb-usb-init.c:308
     cxusb_probe+0x159/0x5e0 drivers/media/usb/dvb-usb/cxusb.c:1634
    
    Fixes: 4d43e13f723e ("V4L/DVB (4643): Multi-input patch for DVB-USB device")
    Cc: stable@vger.kernel.org
    Reported-by: syzbot+7336195c02c1bd2f64e1@syzkaller.appspotmail.com
    Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit becc612df69efcde7a0236ea2b3297134224bc38
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Jun 22 11:06:47 2021 +0200

    ALSA: usb-audio: Fix OOB access at proc output
    
    commit 362372ceb6556f338e230f2d90af27b47f82365a upstream.
    
    At extending the available mixer values for 32bit types, we forgot to
    add the corresponding entries for the format dump in the proc output.
    This may result in OOB access.  Here adds the missing entries.
    
    Fixes: bc18e31c3042 ("ALSA: usb-audio: Fix parameter block size for UAC2 control requests")
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210622090647.14021-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 007a59cb7502e2989bbd69c11e478260b759bceb
Author: Daehwan Jung <dh10.jung@samsung.com>
Date:   Wed Jun 16 18:34:55 2021 +0900

    ALSA: usb-audio: fix rate on Ozone Z90 USB headset
    
    commit aecc19ec404bdc745c781058ac97a373731c3089 upstream.
    
    It mislabels its 96 kHz altsetting and that's why it causes some noise
    
    Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/1623836097-61918-1-git-send-email-dh10.jung@samsung.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04e385f5eb2dedb074fe8d5ac6befb7c6e8f1a9d
Author: Quat Le <quat.le@oracle.com>
Date:   Tue Jun 29 08:58:26 2021 -0700

    scsi: core: Retry I/O for Notify (Enable Spinup) Required error
    
    commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream.
    
    If the device is power-cycled, it takes time for the initiator to transmit
    the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to
    respond to the primitive to become ACTIVE. Retry the I/O request to allow
    the device time to become ACTIVE.
    
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Quat Le <quat.le@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>