Linux 6.1.9

 
acpi: Fix suspend with Xen PV [+ + +]
Author: Juergen Gross <jgross@suse.com>
Date:   Tue Jan 17 16:57:23 2023 +0100

    acpi: Fix suspend with Xen PV
    
    commit fe0ba8c23f9a35b0307eb662f16dd3a75fcdae41 upstream.
    
    Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
    Xen PV guest") missed one code path accessing real_mode_header, leading
    to dereferencing NULL when suspending the system under Xen:
    
        [  348.284004] PM: suspend entry (deep)
        [  348.289532] Filesystems sync: 0.005 seconds
        [  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done.
        [  348.292457] OOM killer disabled.
        [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done.
        [  348.396612] printk: Suspending console(s) (use no_console_suspend to debug)
        [  348.749228] PM: suspend devices took 0.352 seconds
        [  348.769713] ACPI: EC: interrupt blocked
        [  348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c
        [  348.816080] #PF: supervisor read access in kernel mode
        [  348.816081] #PF: error_code(0x0000) - not-present page
        [  348.816083] PGD 0 P4D 0
        [  348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI
        [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1
        [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022
        [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
    
    Fix that by adding an optional acpi callback allowing to skip setting
    the wakeup address, as in the Xen PV case this will be handled by the
    hypervisor anyway.
    
    Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest")
    Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://lore.kernel.org/all/20230117155724.22940-1-jgross%40suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA [+ + +]
Author: Tamim Khan <tamim@fusetak.com>
Date:   Fri Dec 30 00:58:39 2022 -0500

    ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA
    
    [ Upstream commit 77c7248882385397cd7dffe9e1437f59f32ce2de ]
    
    Like the Asus Expertbook B2502CBA and various Asus Vivobook laptops,
    the Asus Expertbook B2402CBA has an ACPI DSDT table that describes IRQ 1
    as ActiveLow while the kernel overrides it to Edge_High. This prevents the
    keyboard from working. To fix this issue, add this laptop to the
    skip_override_table so that the kernel does not override IRQ 1.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216864
    Tested-by: zelenat <zelenat@gmail.com>
    Signed-off-by: Tamim Khan <tamim@fusetak.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Add backlight=native DMI quirk for Asus U46E [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 19 18:24:41 2023 +0100

    ACPI: video: Add backlight=native DMI quirk for Asus U46E
    
    [ Upstream commit e6b3086fddc0065a5ffb947d4d29dd0e6efc327b ]
    
    The Asus U46E backlight tables have a set of interesting problems:
    
    1. Its ACPI tables do make _OSI ("Windows 2012") checks, so
       acpi_osi_is_win8() should return true.
    
       But the tables have 2 sets of _OSI calls, one from the usual global
       _INI method setting a global OSYS variable and a second set of _OSI
       calls from a MSOS method and the MSOS method is the only one calling
       _OSI ("Windows 2012").
    
       The MSOS method only gets called in the following cases:
       1. From some Asus specific WMI methods
       2. From _DOD, which only runs after acpi_video_get_backlight_type()
          has already been called by the i915 driver
       3. From other ACPI video bus methods which never run (see below)
       4. From some EC query callbacks
    
       So when i915 calls acpi_video_get_backlight_type() MSOS has never run
       and acpi_osi_is_win8() returns false, so acpi_video_get_backlight_type()
       returns acpi_video as the desired backlight type, which causes
       the intel_backlight device to not register.
    
    2. _DOD effectively does this:
    
                        Return (Package (0x01)
                        {
                            0x0400
                        })
    
       causing acpi_video_device_in_dod() to return false, which causes
       the acpi_video backlight device to not register.
    
    Leaving the user with no backlight device at all. Note that before 6.1.y
    the i915 driver would register the intel_backlight device unconditionally
    and since that then was the only backlight device userspace would use that.
    
    Add a backlight=native DMI quirk for this special laptop to restore
    the old (and working) behavior of the intel_backlight device registering.
    
    Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor")
    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>

ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 19 17:37:44 2023 +0100

    ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p
    
    [ Upstream commit 9dcb34234b8235144c96103266317da33321077e ]
    
    The HP EliteBook 8460p predates Windows 8, so it defaults to using
    acpi_video# for backlight control.
    
    Starting with the 6.1.y kernels the native radeon_bl0 backlight is hidden
    in this case instead of relying on userspace preferring acpi_video# over
    native backlight devices.
    
    It turns out that for the acpi_video# interface to work on
    the HP EliteBook 8460p, the brightness needs to be set at least once
    through the native interface, which now no longer is done breaking
    backlight control.
    
    The native interface however always works without problems, so add
    a quirk to use native backlight on the EliteBook 8460p to fix this.
    
    Fixes: fb1836c91317 ("ACPI: video: Prefer native over vendor")
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2161428
    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>

ACPI: video: Add backlight=native DMI quirk for HP Pavilion g6-1d80nr [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 19 17:37:43 2023 +0100

    ACPI: video: Add backlight=native DMI quirk for HP Pavilion g6-1d80nr
    
    [ Upstream commit d77596d432cc4142520af32b5388d512e52e0edb ]
    
    The HP Pavilion g6-1d80nr predates Windows 8, so it defaults to using
    acpi_video# for backlight control, but this is non functional on
    this model.
    
    Add a DMI quirk to use the native backlight interface which does
    work properly.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 9dcb34234b82 ("ACPI: video: Add backlight=native DMI quirk for HP EliteBook 8460p")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPI: video: Fix apple gmux detection [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jan 24 11:57:54 2023 +0100

    ACPI: video: Fix apple gmux detection
    
    [ Upstream commit b0935f110cff5d70da05c5cb1670bee0b07b631c ]
    
    Some apple laptop models have an ACPI device with a HID of APP000B
    and that device has an IO resource (so it does not describe the new
    unsupported MMIO based gmux type), but there actually is no gmux
    in the laptop at all.
    
    The gmux_probe() function of the actual apple-gmux driver has code
    to detect this, this code has been factored out into a new
    apple_gmux_detect() helper in apple-gmux.h.
    
    Use this new function to fix acpi_video_get_backlight_type() wrongly
    returning apple_gmux as type on the following laptops:
    
    MacBookPro5,4
    https://pastebin.com/8Xjq7RhS
    
    MacBookPro8,1
    https://linux-hardware.org/?probe=e513cfbadb&log=dmesg
    
    MacBookPro9,2
    https://bugzilla.kernel.org/attachment.cgi?id=278961
    
    MacBookPro10,2
    https://lkml.org/lkml/2014/9/22/657
    
    MacBookPro11,2
    https://forums.fedora-fr.org/viewtopic.php?id=70142
    
    MacBookPro11,4
    https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/mast
    
    Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
    Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/
    Reported-by: Emmanouil Kouroupakis <kartebi@gmail.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230124105754.62167-4-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
affs: initialize fsdata in affs_truncate() [+ + +]
Author: Alexander Potapenko <glider@google.com>
Date:   Tue Jan 10 13:49:30 2023 +0100

    affs: initialize fsdata in affs_truncate()
    
    [ Upstream commit eef034ac6690118c88f357b00e2b3239c9d8575d ]
    
    When aops->write_begin() does not initialize fsdata, KMSAN may report
    an error passing the latter to aops->write_end().
    
    Fix this by unconditionally initializing fsdata.
    
    Fixes: f2b6a16eb8f5 ("fs: affs convert to new aops")
    Suggested-by: Eric Biggers <ebiggers@kernel.org>
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amd-xgbe: Delay AN timeout during KR training [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Jan 11 22:58:52 2023 +0530

    amd-xgbe: Delay AN timeout during KR training
    
    [ Upstream commit 926446ae24c03311a480fb96eb78f0ce7ea6d091 ]
    
    AN restart triggered during KR training not only aborts the KR training
    process but also move the HW to unstable state. Driver has to wait upto
    500ms or until the KR training is completed before restarting AN cycle.
    
    Fixes: 7c12aa08779c ("amd-xgbe: Move the PHY support into amd-xgbe")
    Co-developed-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Sudheesh Mavila <sudheesh.mavila@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

amd-xgbe: TX Flow Ctrl Registers are h/w ver dependent [+ + +]
Author: Raju Rangoju <Raju.Rangoju@amd.com>
Date:   Wed Jan 11 22:58:51 2023 +0530

    amd-xgbe: TX Flow Ctrl Registers are h/w ver dependent
    
    [ Upstream commit 579923d84b04abb6cd4cd1fd9974096a2dd1832b ]
    
    There is difference in the TX Flow Control registers (TFCR) between the
    revisions of the hardware. The older revisions of hardware used to have
    single register per queue. Whereas, the newer revision of hardware (from
    ver 30H onwards) have one register per priority.
    
    Update the driver to use the TFCR based on the reported version of the
    hardware.
    
    Fixes: c5aa9e3b8156 ("amd-xgbe: Initial AMD 10GbE platform driver")
    Co-developed-by: Ajith Nayak <Ajith.Nayak@amd.com>
    Signed-off-by: Ajith Nayak <Ajith.Nayak@amd.com>
    Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
    Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amdgpu: fix build on non-DCN platforms. [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Jan 27 12:15:13 2023 +1000

    amdgpu: fix build on non-DCN platforms.
    
    commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 upstream.
    
    This fixes the build here locally on my 32-bit arm build.
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
arm64: dts: imx8mm-beacon: Fix ecspi2 pinmux [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Fri Dec 2 13:10:37 2022 -0600

    arm64: dts: imx8mm-beacon: Fix ecspi2 pinmux
    
    [ Upstream commit 5225ba9db112ec4ed67da5e4d8b72e618573955e ]
    
    Early hardware did not support hardware handshaking on the UART, but
    final production hardware did.  When the hardware was updated the chip
    select was changed to facilitate hardware handshaking on UART3.  Fix the
    ecspi2 pin mux to eliminate a pin conflict with UART3 and allow the
    EEPROM to operate again.
    
    Fixes: 4ce01ce36d77 ("arm64: dts: imx8mm-beacon: Enable RTS-CTS on UART3")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mm-venice-gw7901: fix USB2 controller OC polarity [+ + +]
Author: Tim Harvey <tharvey@gateworks.com>
Date:   Wed Dec 28 12:26:06 2022 -0800

    arm64: dts: imx8mm-venice-gw7901: fix USB2 controller OC polarity
    
    [ Upstream commit ae066f374687d7dd06bb8c732f66d6ab3c3fd480 ]
    
    The GW7901 has USB2 routed to a USB VBUS supply with over-current
    protection via an active-low pin. Define the OC pin polarity properly.
    
    Fixes: 2b1649a83afc ("arm64: dts: imx: Add i.mx8mm Gateworks gw7901 dts support")
    Signed-off-by: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp-evk: pcie0-refclk cosmetic cleanup [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Sun Jan 1 12:50:42 2023 +0800

    arm64: dts: imx8mp-evk: pcie0-refclk cosmetic cleanup
    
    [ Upstream commit 9a65c759e4666476a6642ad87b4db8a67cb957d0 ]
    
    Use the correct indention.
    
    Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support")
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp-phycore-som: Remove invalid PMIC property [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 13:29:11 2022 -0300

    arm64: dts: imx8mp-phycore-som: Remove invalid PMIC property
    
    [ Upstream commit cfd04dd1c4b6c33afc2a934b957d71cf8ddd1539 ]
    
    'regulator-compatible' is not a valid property according to
    nxp,pca9450-regulator.yaml and causes the following warning:
    
      DTC_CHK arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk2.dtb
    ...
    pmic@25: regulators:LDO1: Unevaluated properties are not allowed ('regulator-compatible' was unexpected)
    
    Remove the invalid 'regulator-compatible' property.
    
    Cc: Teresa Remmet <t.remmet@phytec.de>
    Fixes: 88f7f6bcca37 ("arm64: dts: freescale: Add support for phyBOARD-Pollux-i.MX8MP")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Reviewed-by: Teresa Remmet <t.remmet@phytec.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp: Fix missing GPC Interrupt [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Sat Dec 17 12:08:48 2022 -0600

    arm64: dts: imx8mp: Fix missing GPC Interrupt
    
    [ Upstream commit b3b75ace2085aca623c57e04ea7218ae690090fb ]
    
    The GPC node references an interrupt parent, but it doesn't
    state the interrupt itself.  According to the TRM, this IRQ
    is 87. This also eliminate an error detected from dt_binding_check
    
    Fixes: fc0f05124621 ("arm64: dts: imx8mp: add GPC node with GPU power domains")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx8mp: Fix power-domain typo [+ + +]
Author: Adam Ford <aford173@gmail.com>
Date:   Sat Dec 17 12:08:49 2022 -0600

    arm64: dts: imx8mp: Fix power-domain typo
    
    [ Upstream commit 10e2f328bd900787fd2db24e474f87e1d525ccc4 ]
    
    dt_binding_check detects an issue with the pgc_hsiomix power
    domain:
      pgc: 'power-domains@17' does not match any of the regexes
    
    This is because 'power-domains' should be 'power-domain'
    
    Fixes: 2ae42e0c0b67 ("arm64: dts: imx8mp: add HSIO power-domains")
    Signed-off-by: Adam Ford <aford173@gmail.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: imx93-11x11-evk: correct clock and strobe pad setting [+ + +]
Author: Haibo Chen <haibo.chen@nxp.com>
Date:   Thu Dec 8 17:06:58 2022 +0800

    arm64: dts: imx93-11x11-evk: correct clock and strobe pad setting
    
    [ Upstream commit 62f0147fd4d86620853bee027800f988d3013656 ]
    
    For clock and strobe pad of usdhc, need to config as pull down.
    Current pad config set these pad as both pull up and pull down,
    this is wrong, so fix it here.
    Find this issue when enable HS400ES mode on one Micron eMMC chip,
    CMD8 always meet CRC error in HS400ES/HS400 mode.
    
    Fixes: e37907bd8294 ("arm64: dts: freescale: add i.MX93 11x11 EVK basic support")
    Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: marvell: AC5/AC5X: Fix address for UART1 [+ + +]
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date:   Thu Dec 15 15:54:02 2022 +1300

    arm64: dts: marvell: AC5/AC5X: Fix address for UART1
    
    [ Upstream commit 80502ffab2fa92ba9777e381efea2efddc348d13 ]
    
    The correct address offset is 0x12100.
    
    Fixes: 31be791e26cf ("arm64: dts: marvell: Add UART1-3 for AC5/AC5X")
    Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8992-libra: Fix the memory map [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Dec 19 14:19:18 2022 +0100

    arm64: dts: qcom: msm8992-libra: Fix the memory map
    
    [ Upstream commit 69876bc6fd4de3ad2dc7826fe269e91fa2c1807f ]
    
    The memory map was wrong. Fix it to prevent the device from randomly
    rebooting.
    
    Fixes: 0f5cdb31e850 ("arm64: dts: qcom: Add Xiaomi Libra (Mi 4C) device tree")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221219131918.446587-2-konrad.dybcio@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: msm8992: Don't use sfpb mutex [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Dec 19 14:19:17 2022 +0100

    arm64: dts: qcom: msm8992: Don't use sfpb mutex
    
    [ Upstream commit 2bd5ab93335bf2c4d22c8db427822ae637ed8dc3 ]
    
    MSM8992 uses the same mutex hardware as MSM8994. This was wrong
    from the start, but never presented as an issue until the sfpb
    compatible was given different driver data.
    
    Fixes: 6a6d1978f9c0 ("arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support")
    Reported-by: Eugene Lepshy <fekz115@gmail.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221219131918.446587-1-konrad.dybcio@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc8280xp: fix primary USB-DP PHY reset [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Nov 21 09:50:57 2022 +0100

    arm64: dts: qcom: sc8280xp: fix primary USB-DP PHY reset
    
    [ Upstream commit ee4e530bdde29a69c58656a919545251a782674e ]
    
    The vendor kernel is using the GCC_USB4_DP_PHY_PRIM_BCR and
    GCC_USB4_1_DP_PHY_PRIM_BCR resets for the USB4-USB3-DP QMP PHYs.
    
    Update the primary USB-DP PHY node to match.
    
    Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221121085058.31213-15-johan+linaro@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: verdin-imx8mm: fix dahlia audio playback [+ + +]
Author: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Date:   Thu Dec 1 13:55:48 2022 +0100

    arm64: dts: verdin-imx8mm: fix dahlia audio playback
    
    [ Upstream commit 0d1d030f00f3f3eea04017cbd50ffe44a2842ebc ]
    
    Set optional `simple-audio-card,mclk-fs` parameter to ensure a proper
    clock to the wm8904 audio codec. Without this change with an audio
    stream rate of 44.1 kHz the playback is completely distorted.
    
    Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini")
    Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: verdin-imx8mm: fix dev board audio playback [+ + +]
Author: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Date:   Wed Dec 7 11:27:49 2022 +0100

    arm64: dts: verdin-imx8mm: fix dev board audio playback
    
    [ Upstream commit 6c620a30515c494b5eeb3dc0e40d3220ea04c53b ]
    
    Set optional `simple-audio-card,mclk-fs` parameter to ensure a proper
    clock to the nau8822 audio codec. Without this change with an audio
    stream rate of 44.1 kHz the playback is faster.
    Set the MCLK at the right frequency, codec can properly use it to
    generate 44.1 kHz I2S-FS.
    
    Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini")
    Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
    Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: efi: Account for the EFI runtime stack in stack unwinder [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Dec 9 12:10:13 2022 +0100

    arm64: efi: Account for the EFI runtime stack in stack unwinder
    
    [ Upstream commit 7ea55715c421d22c1b63f7129cae6a654091b695 ]
    
    The EFI runtime services run from a dedicated stack now, and so the
    stack unwinder needs to be informed about this.
    
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: efi: Avoid workqueue to check whether EFI runtime is live [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Oct 28 16:39:14 2022 +0200

    arm64: efi: Avoid workqueue to check whether EFI runtime is live
    
    [ Upstream commit 8a9a1a18731eb123e35f48176380a18b9782845e ]
    
    Comparing current_work() against efi_rts_work.work is sufficient to
    decide whether current is currently running EFI runtime services code at
    any level in its call stack.
    
    However, there are other potential users of the EFI runtime stack, such
    as the ACPI subsystem, which may invoke efi_call_virt_pointer()
    directly, and so any sync exceptions occurring in firmware during those
    calls are currently misidentified.
    
    So instead, let's check whether the stashed value of the thread stack
    pointer points into current's thread stack. This can only be the case if
    current was interrupted while running EFI runtime code. Note that this
    implies that we should clear the stashed value after switching back, to
    avoid false positives.
    
    Reviewed-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: efi: Recover from synchronous exceptions occurring in firmware [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Fri Oct 28 16:39:14 2022 +0200

    arm64: efi: Recover from synchronous exceptions occurring in firmware
    
    [ Upstream commit e8dfdf3162eb549d064b8c10b1564f7e8ee82591 ]
    
    Unlike x86, which has machinery to deal with page faults that occur
    during the execution of EFI runtime services, arm64 has nothing like
    that, and a synchronous exception raised by firmware code brings down
    the whole system.
    
    With more EFI based systems appearing that were not built to run Linux
    (such as the Windows-on-ARM laptops based on Qualcomm SOCs), as well as
    the introduction of PRM (platform specific firmware routines that are
    callable just like EFI runtime services), we are more likely to run into
    issues of this sort, and it is much more likely that we can identify and
    work around such issues if they don't bring down the system entirely.
    
    Since we already use a EFI runtime services call wrapper in assembler,
    we can quite easily add some code that captures the execution state at
    the point where the call is made, allowing us to revert to this state
    and proceed execution if the call triggered a synchronous exception.
    
    Given that the kernel and the firmware don't share any data structures
    that could end up in an indeterminate state, we can happily continue
    running, as long as we mark the EFI runtime services as unavailable from
    that point on.
    
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Stable-dep-of: 8a9a1a18731e ("arm64: efi: Avoid workqueue to check whether EFI runtime is live")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignment [+ + +]
Author: Giulio Benetti <giulio.benetti@benettiengineering.com>
Date:   Tue Dec 13 20:24:03 2022 +0100

    ARM: 9280/1: mm: fix warning on phys_addr_t to void pointer assignment
    
    commit a4e03921c1bb118e6718e0a3b0322a2c13ed172b upstream.
    
    zero_page is a void* pointer but memblock_alloc() returns phys_addr_t type
    so this generates a warning while using clang and with -Wint-error enabled
    that becomes and error. So let's cast the return of memblock_alloc() to
    (void *).
    
    Cc: <stable@vger.kernel.org> # 4.14.x +
    Fixes: 340a982825f7 ("ARM: 9266/1: mm: fix no-MMU ZERO_PAGE() implementation")
    Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: at91: sam9x60: fix the ddr clock for sam9x60 [+ + +]
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date:   Thu Dec 8 13:52:41 2022 +0200

    ARM: dts: at91: sam9x60: fix the ddr clock for sam9x60
    
    [ Upstream commit 9bfa2544dbd1133f0b0af4e967de3bb9c1e3a497 ]
    
    The 2nd DDR clock for sam9x60 DDR controller is peripheral clock with
    id 49.
    
    Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
    Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Link: https://lore.kernel.org/r/20221208115241.36312-1-claudiu.beznea@microchip.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6qdl-gw560x: Remove incorrect 'uart-has-rtscts' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 17:22:59 2022 -0300

    ARM: dts: imx6qdl-gw560x: Remove incorrect 'uart-has-rtscts'
    
    [ Upstream commit 9dfbc72256b5de608ad10989bcbafdbbd1ac8d4e ]
    
    The following build warning is seen when running:
    
    make dtbs_check DT_SCHEMA_FILES=fsl-imx-uart.yaml
    
    arch/arm/boot/dts/imx6dl-gw560x.dtb: serial@2020000: rts-gpios: False schema does not allow [[20, 1, 0]]
            From schema: Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
    
    The imx6qdl-gw560x board does not expose the UART RTS and CTS
    as native UART pins, so 'uart-has-rtscts' should not be used.
    
    Using 'uart-has-rtscts' with 'rts-gpios' is an invalid combination
    detected by serial.yaml.
    
    Fix the problem by removing the incorrect 'uart-has-rtscts' property.
    
    Fixes: b8a559feffb2 ("ARM: dts: imx: add Gateworks Ventana GW5600 support")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Acked-by: Tim Harvey <tharvey@gateworks.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx6ul-pico-dwarf: Use 'clock-frequency' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 13:31:23 2022 -0300

    ARM: dts: imx6ul-pico-dwarf: Use 'clock-frequency'
    
    [ Upstream commit 94e2cf1e0db5b06c7a6ae0878c5cbec925819a8a ]
    
    'clock_frequency' is not a valid property.
    
    Use the correct 'clock-frequency' instead.
    
    Fixes: 47246fafef84 ("ARM: dts: imx6ul-pico: Add support for the dwarf baseboard")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: imx7d-pico: Use 'clock-frequency' [+ + +]
Author: Fabio Estevam <festevam@denx.de>
Date:   Mon Nov 21 13:31:24 2022 -0300

    ARM: dts: imx7d-pico: Use 'clock-frequency'
    
    [ Upstream commit f4dd0845c4f1f5371f1e06fef0e4a1734a2db964 ]
    
    'clock_frequency' is not a valid property.
    
    Use the correct 'clock-frequency' instead.
    
    Fixes: 8b646cfb84c3 ("ARM: dts: imx7d-pico: Add support for the dwarf baseboard")
    Fixes: 6418fd92417f ("ARM: dts: imx7d-pico: Add support for the nymph baseboard")
    Signed-off-by: Fabio Estevam <festevam@denx.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp151a-prtt1l [+ + +]
Author: Patrice Chotard <patrice.chotard@foss.st.com>
Date:   Mon Dec 12 09:51:42 2022 +0100

    ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp151a-prtt1l
    
    [ Upstream commit 175281f80695569c7f9cf062e5d0ddc4addc109f ]
    
    Chip select pinctrl phandle was missing in several stm32mp15x based boards.
    
    Fixes: ea99a5a02ebc ("ARM: dts: stm32: Create separate pinmux for qspi cs pin in stm32mp15-pinctrl.dtsi")
    
    Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Cc: Oleksij Rempel <o.rempel@pengutronix.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp157c-emstamp-argon [+ + +]
Author: Patrice Chotard <patrice.chotard@foss.st.com>
Date:   Mon Dec 12 09:51:41 2022 +0100

    ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp157c-emstamp-argon
    
    [ Upstream commit 732dbcf52f74b254a7ddd4226e0b9638e1e7aeff ]
    
    Chip select pinctrl phandle was missing in several stm32mp15x based boards.
    
    Fixes: ea99a5a02ebc ("ARM: dts: stm32: Create separate pinmux for qspi cs pin in stm32mp15-pinctrl.dtsi")
    
    Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Cc: Reinhold Mueller <reinhold.mueller@emtrion.com>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp15xx-dhcom-som [+ + +]
Author: Patrice Chotard <patrice.chotard@foss.st.com>
Date:   Mon Dec 12 09:51:40 2022 +0100

    ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp15xx-dhcom-som
    
    [ Upstream commit 21d83512bf2bd25ebed467151fd2bcd0cca7dc9a ]
    
    Chip select pinctrl phandle was missing in several stm32mp15x based boards.
    
    Fixes: ea99a5a02ebc ("ARM: dts: stm32: Create separate pinmux for qspi cs pin in stm32mp15-pinctrl.dtsi")
    
    Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Cc: linux-arm-kernel@lists.infradead.org
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp15xx-dhcor-som [+ + +]
Author: Patrice Chotard <patrice.chotard@foss.st.com>
Date:   Mon Dec 12 09:51:39 2022 +0100

    ARM: dts: stm32: Fix qspi pinctrl phandle for stm32mp15xx-dhcor-som
    
    [ Upstream commit 7ffd2266bd32d9f31a4e918443c733906cff0d19 ]
    
    Chip select pinctrl phandle was missing in several stm32mp15x based boards.
    
    Fixes: ea99a5a02ebc ("ARM: dts: stm32: Create separate pinmux for qspi cs pin in stm32mp15-pinctrl.dtsi")
    
    Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Cc: Marek Vasut <marex@denx.de>
    Cc: Alexandre Torgue <alexandre.torgue@st.com>
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Cc: linux-arm-kernel@lists.infradead.org
    Reviewed-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: imx: add missing of_node_put() [+ + +]
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Thu Dec 8 17:54:03 2022 +0100

    ARM: imx: add missing of_node_put()
    
    [ Upstream commit 87b30c4b0efb6a194a7b8eac2568a3da520d905f ]
    
    Calling of_find_compatible_node() returns a node pointer with refcount
    incremented. Use of_node_put() on it when done.
    The patch fixes the same problem on different i.MX platforms.
    
    Fixes: 8b88f7ef31dde ("ARM: mx25: Retrieve IIM base from dt")
    Fixes: 94b2bec1b0e05 ("ARM: imx27: Retrieve the SYSCTRL base address from devicetree")
    Fixes: 3172225d45bd9 ("ARM: imx31: Retrieve the IIM base address from devicetree")
    Fixes: f68ea682d1da7 ("ARM: imx35: Retrieve the IIM base address from devicetree")
    Fixes: ee18a7154ee08 ("ARM: imx5: retrieve iim base from device tree")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Reviewed-by: Fabio Estevam <festevam@gmail.com>
    Reviewed-by: Martin Kaiser <martin@kaiser.cx>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: amd: yc: Add ASUS M5402RA into DMI table [+ + +]
Author: Aniol Martí <aniol@aniolmarti.cat>
Date:   Tue Dec 27 23:49:32 2022 +0100

    ASoC: amd: yc: Add ASUS M5402RA into DMI table
    
    [ Upstream commit a0dd7fcab5cd221fa960f594c586e1f9f16c02c0 ]
    
    ASUS VivoBook 13 OLED (M5402RA) needs this quirk to get the built-in microphone working properly.
    
    Signed-off-by: Aniol Martí <aniol@aniolmarti.cat>
    Link: https://lore.kernel.org/r/20221227224932.9771-1-aniol@aniolmarti.cat
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: amd: yc: Add Razer Blade 14 2022 into DMI table [+ + +]
Author: Wim Van Boven <wimvanboven@gmail.com>
Date:   Fri Dec 16 09:18:27 2022 +0100

    ASoC: amd: yc: Add Razer Blade 14 2022 into DMI table
    
    [ Upstream commit 68506a173dd700c2bd794dcc3489edcdb8ee35c6 ]
    
    Razer Blade 14 (2022) - RZ09-0427 needs the quirk to enable the built in microphone
    
    Signed-off-by: Wim Van Boven <wimvanboven@gmail.com>
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Link: https://lore.kernel.org/r/20221216081828.12382-1-wimvanboven@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 6 23:15:07 2023 +0000

    ASoC: fsl-asoc-card: Fix naming of AC'97 CODEC widgets
    
    [ Upstream commit 242fc66ae6e1e2b8519daacc7590a73cd0e8a6e4 ]
    
    The fsl-asoc-card AC'97 support currently tries to route to Playback and
    Capture widgets provided by the AC'97 CODEC. This doesn't work since the
    generic AC'97 driver registers with an "AC97" at the front of the stream
    and hence widget names, update to reflect reality. It's not clear to me
    if or how this ever worked.
    
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-2-a5d7469d4f67@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_micfil: Correct the number of steps on SX controls [+ + +]
Author: Chancel Liu <chancel.liu@nxp.com>
Date:   Wed Jan 4 10:57:54 2023 +0800

    ASoC: fsl_micfil: Correct the number of steps on SX controls
    
    [ Upstream commit cdfa92eb90f5770b26a79824ef213ebdbbd988b1 ]
    
    The parameter "max" of SOC_SINGLE_SX_TLV() means the number of steps
    rather than maximum value. This patch corrects the minimum value to -8
    and the number of steps to 15.
    
    Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Link: https://lore.kernel.org/r/20230104025754.3019235-1-chancel.liu@nxp.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC [+ + +]
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 6 23:15:06 2023 +0000

    ASoC: fsl_ssi: Rename AC'97 streams to avoid collisions with AC'97 CODEC
    
    [ Upstream commit 8c6a42b5b0ed6f96624f56954e93eeae107440a6 ]
    
    The SSI driver calls the AC'97 playback and transmit streams "AC97 Playback"
    and "AC97 Capture" respectively. This is the same name used by the generic
    AC'97 CODEC driver in ASoC, creating confusion for the Freescale ASoC card
    when it attempts to use these widgets in routing. Add a "CPU" in the name
    like the regular DAIs registered by the driver to disambiguate.
    
    Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20230106-asoc-udoo-probe-v1-1-a5d7469d4f67@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8186: Add machine support for max98357a [+ + +]
Author: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
Date:   Wed Dec 28 19:57:56 2022 +0800

    ASoC: mediatek: mt8186: Add machine support for max98357a
    
    [ Upstream commit 8a54f666db581bbf07494cca44a0124acbced581 ]
    
    Add support for mt8186 with mt6366 and max98357a.
    
    Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com>
    Link: https://lore.kernel.org/r/20221228115756.28014-1-allen-kh.cheng@mediatek.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8186: support rt5682s_max98360 [+ + +]
Author: tongjian <tongjian@huaqin.corp-partner.google.com>
Date:   Wed Dec 28 20:22:29 2022 +0800

    ASoC: mediatek: mt8186: support rt5682s_max98360
    
    [ Upstream commit 6e1dbf694d7cd1737ee14866e9e05016ccc9ac40 ]
    
    Add support for using the rt5682s codec together with max98360a on
    MT8186-MT6366-RT1019-RT5682S machines.
    
    Signed-off-by: tongjian <tongjian@huaqin.corp-partner.google.com>
    Link: https://lore.kernel.org/r/20221228122230.3818533-2-tongjian@huaqin.corp-partner.google.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: Add FW state to debugfs [+ + +]
Author: Curtis Malainey <cujomalainey@chromium.org>
Date:   Tue Dec 20 14:56:29 2022 +0200

    ASoC: SOF: Add FW state to debugfs
    
    [ Upstream commit 9a9134fd56f6ba614ff7b2b3b0bac0bf1d0dc0c9 ]
    
    Allow system health detection mechanisms to check the FW state, this
    will allow them to check if the FW is in its "crashed" state going
    forward to help automatically diagnose driver state.
    
    Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20221220125629.8469-4-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: pm: Always tear down pipelines before DSP suspend [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Dec 20 14:56:28 2022 +0200

    ASoC: SOF: pm: Always tear down pipelines before DSP suspend
    
    [ Upstream commit d185e0689abc98ef55fb7a7d75aa0c48a0ed5838 ]
    
    When the DSP is suspended while the firmware is in the crashed state, we
    skip tearing down the pipelines. This means that the widget reference
    counts will not get to reset to 0 before suspend. This will lead to
    errors with resuming audio after system resume. To fix this, invoke the
    tear_down_all_pipelines op before skipping to DSP suspend.
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Curtis Malainey <cujomalainey@chromium.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20221220125629.8469-3-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: SOF: pm: Set target state earlier [+ + +]
Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Date:   Tue Dec 20 14:56:27 2022 +0200

    ASoC: SOF: pm: Set target state earlier
    
    [ Upstream commit 6f95eec6fb89e195dbdf30de65553c7fc57d9372 ]
    
    If the DSP crashes before the system suspends, the setting of target state
    will be skipped because the firmware state will no longer be
    SOF_FW_BOOT_COMPLETE. This leads to the incorrect assumption that the
    DSP should suspend to D0I3 instead of suspending to D3. To fix this,
    set the target_state before we skip to DSP suspend even when the DSP has
    crashed.
    
    Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Curtis Malainey <cujomalainey@chromium.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://lore.kernel.org/r/20221220125629.8469-2-peter.ujfalusi@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: support machine driver with max98360 [+ + +]
Author: Mars Chen <chenxiangrui@huaqin.corp-partner.google.com>
Date:   Wed Dec 28 18:38:12 2022 +0800

    ASoC: support machine driver with max98360
    
    [ Upstream commit 810948f45d99c46b60852ef2a5a2777c12d6bb3e ]
    
    Signed-off-by: Mars Chen <chenxiangrui@huaqin.corp-partner.google.com>
    Link: https://lore.kernel.org/r/20221228103812.450956-1-chenxiangrui@huaqin.corp-partner.google.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: pata_cs5535: Don't build on UML [+ + +]
Author: Peter Foley <pefoley2@pefoley.com>
Date:   Thu Jan 12 23:37:06 2023 -0500

    ata: pata_cs5535: Don't build on UML
    
    [ Upstream commit 22eebaa631c40f3dac169ba781e0de471b83bf45 ]
    
    This driver uses MSR functions that aren't implemented under UML.
    Avoid building it to prevent tripping up allyesconfig.
    
    e.g.
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x3a3): undefined reference to `__tracepoint_read_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x3d2): undefined reference to `__tracepoint_write_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x457): undefined reference to `__tracepoint_write_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x481): undefined reference to `do_trace_write_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x4d5): undefined reference to `do_trace_write_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x4f5): undefined reference to `do_trace_read_msr'
    /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: pata_cs5535.c:(.text+0x51c): undefined reference to `do_trace_write_msr'
    
    Signed-off-by: Peter Foley <pefoley2@pefoley.com>
    Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block/rnbd-clt: fix wrong max ID in ida_alloc_max [+ + +]
Author: Guoqing Jiang <guoqing.jiang@linux.dev>
Date:   Fri Dec 30 09:09:26 2022 +0800

    block/rnbd-clt: fix wrong max ID in ida_alloc_max
    
    [ Upstream commit 9d6033e350694a67885605674244d43c9559dc36 ]
    
    We need to pass 'end - 1' to ida_alloc_max after switch from
    ida_simple_get to ida_alloc_max.
    
    Otherwise smatch warns.
    
    drivers/block/rnbd/rnbd-clt.c:1460 init_dev() error: Calling ida_alloc_max() with a 'max' argument which is a power of 2. -1 missing?
    
    Fixes: 24afc15dbe21 ("block/rnbd: Remove a useless mutex")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Guoqing Jiang <guoqing.jiang@linux.dev>
    Acked-by: Jack Wang <jinpu.wang@ionos.com>
    Link: https://lore.kernel.org/r/20221230010926.32243-1-guoqing.jiang@linux.dev
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: ublk: move ublk_chr_class destroying after devices are removed [+ + +]
Author: Ming Lei <ming.lei@redhat.com>
Date:   Thu Jan 26 19:53:46 2023 +0800

    block: ublk: move ublk_chr_class destroying after devices are removed
    
    [ Upstream commit 8e4ff684762b6503db45e8906e258faee080c336 ]
    
    The 'ublk_chr_class' is needed when deleting ublk char devices in
    ublk_exit(), so move it after devices(idle) are removed.
    
    Fixes the following warning reported by Harris, James R:
    
    [  859.178950] sysfs group 'power' not found for kobject 'ublkc0'
    [  859.178962] WARNING: CPU: 3 PID: 1109 at fs/sysfs/group.c:278 sysfs_remove_group+0x9c/0xb0
    
    Reported-by: "Harris, James R" <james.r.harris@intel.com>
    Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver")
    Link: https://lore.kernel.org/linux-block/Y9JlFmSgDl3+zy3N@T590/T/#t
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Tested-by: Jim Harris <james.r.harris@intel.com>
    Link: https://lore.kernel.org/r/20230126115346.263344-1-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: Fix a buffer overflow in mgmt_mesh_add() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Mon Dec 12 05:08:28 2022 -0800

    Bluetooth: Fix a buffer overflow in mgmt_mesh_add()
    
    [ Upstream commit 2185e0fdbb2137f22a9dd9fcbf6481400d56299b ]
    
    Smatch Warning:
    net/bluetooth/mgmt_util.c:375 mgmt_mesh_add() error: __memcpy()
    'mesh_tx->param' too small (48 vs 50)
    
    Analysis:
    
    'mesh_tx->param' is array of size 48. This is the destination.
    u8 param[sizeof(struct mgmt_cp_mesh_send) + 29]; // 19 + 29 = 48.
    
    But in the caller 'mesh_send' we reject only when len > 50.
    len > (MGMT_MESH_SEND_SIZE + 31) // 19 + 31 = 50.
    
    Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Brian Gix <brian.gix@intel.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: Fix possible deadlock in rfcomm_sk_state_change [+ + +]
Author: Ying Hsu <yinghsu@chromium.org>
Date:   Wed Jan 11 03:16:14 2023 +0000

    Bluetooth: Fix possible deadlock in rfcomm_sk_state_change
    
    [ Upstream commit 1d80d57ffcb55488f0ec0b77928d4f82d16b6a90 ]
    
    syzbot reports a possible deadlock in rfcomm_sk_state_change [1].
    While rfcomm_sock_connect acquires the sk lock and waits for
    the rfcomm lock, rfcomm_sock_release could have the rfcomm
    lock and hit a deadlock for acquiring the sk lock.
    Here's a simplified flow:
    
    rfcomm_sock_connect:
      lock_sock(sk)
      rfcomm_dlc_open:
        rfcomm_lock()
    
    rfcomm_sock_release:
      rfcomm_sock_shutdown:
        rfcomm_lock()
        __rfcomm_dlc_close:
            rfcomm_k_state_change:
              lock_sock(sk)
    
    This patch drops the sk lock before calling rfcomm_dlc_open to
    avoid the possible deadlock and holds sk's reference count to
    prevent use-after-free after rfcomm_dlc_open completes.
    
    Reported-by: syzbot+d7ce59...@syzkaller.appspotmail.com
    Fixes: 1804fdf6e494 ("Bluetooth: btintel: Combine setting up MSFT extension")
    Link: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218 [1]
    
    Signed-off-by: Ying Hsu <yinghsu@chromium.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_conn: Fix memory leaks [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Wed Jan 4 14:46:23 2023 +0800

    Bluetooth: hci_conn: Fix memory leaks
    
    [ Upstream commit 3aa21311f36d8a2730c7ccef37235e951f23927b ]
    
    When hci_cmd_sync_queue() failed in hci_le_terminate_big() or
    hci_le_big_terminate(), the memory pointed by variable d is not freed,
    which will cause memory leak. Add release process to error path.
    
    Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_event: Fix Invalid wait context [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Jan 10 17:04:46 2023 -0800

    Bluetooth: hci_event: Fix Invalid wait context
    
    [ Upstream commit e9d50f76fe1f7f6f251114919247445fb5cb3734 ]
    
    This fixes the following trace caused by attempting to lock
    cmd_sync_work_lock while holding the rcu_read_lock:
    
    kworker/u3:2/212 is trying to lock:
    ffff888002600910 (&hdev->cmd_sync_work_lock){+.+.}-{3:3}, at:
    hci_cmd_sync_queue+0xad/0x140
    other info that might help us debug this:
    context-{4:4}
    4 locks held by kworker/u3:2/212:
     #0: ffff8880028c6530 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
     process_one_work+0x4dc/0x9a0
     #1: ffff888001aafde0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
     at: process_one_work+0x4dc/0x9a0
     #2: ffff888002600070 (&hdev->lock){+.+.}-{3:3}, at:
     hci_cc_le_set_cig_params+0x64/0x4f0
     #3: ffffffffa5994b00 (rcu_read_lock){....}-{1:2}, at:
     hci_cc_le_set_cig_params+0x2f9/0x4f0
    
    Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: cancel cmd_timer if hci_open failed [+ + +]
Author: Archie Pusaka <apusaka@chromium.org>
Date:   Thu Jan 26 16:36:13 2023 +0300

    Bluetooth: hci_sync: cancel cmd_timer if hci_open failed
    
    commit 97dfaf073f5881c624856ef293be307b6166115c upstream.
    
    If a command is already sent, we take care of freeing it, but we
    also need to cancel the timeout as well.
    
    Signed-off-by: Archie Pusaka <apusaka@chromium.org>
    Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_sync: fix memory leak in hci_update_adv_data() [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Mon Jan 9 09:26:51 2023 +0800

    Bluetooth: hci_sync: fix memory leak in hci_update_adv_data()
    
    [ Upstream commit 1ed8b37cbaf14574c779064ef1372af62e8ba6aa ]
    
    When hci_cmd_sync_queue() failed in hci_update_adv_data(), inst_ptr is
    not freed, which will cause memory leak, convert to use ERR_PTR/PTR_ERR
    to pass the instance to callback so no memory needs to be allocated.
    
    Fixes: 651cd3d65b0f ("Bluetooth: convert hci_update_adv_data to hci_sync")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Avoid circular locking dependency [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Dec 6 16:34:42 2022 -0800

    Bluetooth: ISO: Avoid circular locking dependency
    
    [ Upstream commit 241f51931c35085449502c10f64fb3ecd6e02171 ]
    
    This attempts to avoid circular locking dependency between sock_lock
    and hdev_lock:
    
    WARNING: possible circular locking dependency detected
    6.0.0-rc7-03728-g18dd8ab0a783 #3 Not tainted
    ------------------------------------------------------
    kworker/u3:2/53 is trying to acquire lock:
    ffff888000254130 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}, at:
    iso_conn_del+0xbd/0x1d0
    but task is already holding lock:
    ffffffff9f39a080 (hci_cb_list_lock){+.+.}-{3:3}, at:
    hci_le_cis_estabilished_evt+0x1b5/0x500
    which lock already depends on the new lock.
    the existing dependency chain (in reverse order) is:
    -> #2 (hci_cb_list_lock){+.+.}-{3:3}:
           __mutex_lock+0x10e/0xfe0
           hci_le_remote_feat_complete_evt+0x17f/0x320
           hci_event_packet+0x39c/0x7d0
           hci_rx_work+0x2bf/0x950
           process_one_work+0x569/0x980
           worker_thread+0x2a3/0x6f0
           kthread+0x153/0x180
           ret_from_fork+0x22/0x30
    -> #1 (&hdev->lock){+.+.}-{3:3}:
           __mutex_lock+0x10e/0xfe0
           iso_connect_cis+0x6f/0x5a0
           iso_sock_connect+0x1af/0x710
           __sys_connect+0x17e/0x1b0
           __x64_sys_connect+0x37/0x50
           do_syscall_64+0x43/0x90
           entry_SYSCALL_64_after_hwframe+0x62/0xcc
    -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:
           __lock_acquire+0x1b51/0x33d0
           lock_acquire+0x16f/0x3b0
           lock_sock_nested+0x32/0x80
           iso_conn_del+0xbd/0x1d0
           iso_connect_cfm+0x226/0x680
           hci_le_cis_estabilished_evt+0x1ed/0x500
           hci_event_packet+0x39c/0x7d0
           hci_rx_work+0x2bf/0x950
           process_one_work+0x569/0x980
           worker_thread+0x2a3/0x6f0
           kthread+0x153/0x180
           ret_from_fork+0x22/0x30
    other info that might help us debug this:
    Chain exists of:
      sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> &hdev->lock --> hci_cb_list_lock
     Possible unsafe locking scenario:
           CPU0                    CPU1
           ----                    ----
      lock(hci_cb_list_lock);
                                   lock(&hdev->lock);
                                   lock(hci_cb_list_lock);
      lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);
     *** DEADLOCK ***
    4 locks held by kworker/u3:2/53:
     #0: ffff8880021d9130 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
     process_one_work+0x4ad/0x980
     #1: ffff888002387de0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
     at: process_one_work+0x4ad/0x980
     #2: ffff888001ac0070 (&hdev->lock){+.+.}-{3:3}, at:
     hci_le_cis_estabilished_evt+0xc3/0x500
     #3: ffffffff9f39a080 (hci_cb_list_lock){+.+.}-{3:3}, at:
     hci_le_cis_estabilished_evt+0x1b5/0x500
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Stable-dep-of: 6a5ad251b7cd ("Bluetooth: ISO: Fix possible circular locking dependency")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: ISO: Fix possible circular locking dependency [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Tue Jan 10 13:24:51 2023 -0800

    Bluetooth: ISO: Fix possible circular locking dependency
    
    [ Upstream commit 6a5ad251b7cdb990a3705428aef408433f05614a ]
    
    This attempts to fix the following trace:
    
    kworker/u3:1/184 is trying to acquire lock:
    ffff888001888130 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}, at:
    iso_connect_cfm+0x2de/0x690
    
    but task is already holding lock:
    ffff8880028d1c20 (&conn->lock){+.+.}-{2:2}, at:
    iso_connect_cfm+0x265/0x690
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 (&conn->lock){+.+.}-{2:2}:
           lock_acquire+0x176/0x3d0
           _raw_spin_lock+0x2a/0x40
           __iso_sock_close+0x1dd/0x4f0
           iso_sock_release+0xa0/0x1b0
           sock_close+0x5e/0x120
           __fput+0x102/0x410
           task_work_run+0xf1/0x160
           exit_to_user_mode_prepare+0x170/0x180
           syscall_exit_to_user_mode+0x19/0x50
           do_syscall_64+0x4e/0x90
           entry_SYSCALL_64_after_hwframe+0x62/0xcc
    
    -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:
           check_prev_add+0xfc/0x1190
           __lock_acquire+0x1e27/0x2750
           lock_acquire+0x176/0x3d0
           lock_sock_nested+0x32/0x80
           iso_connect_cfm+0x2de/0x690
           hci_cc_le_setup_iso_path+0x195/0x340
           hci_cmd_complete_evt+0x1ae/0x500
           hci_event_packet+0x38e/0x7c0
           hci_rx_work+0x34c/0x980
           process_one_work+0x5a5/0x9a0
           worker_thread+0x89/0x6f0
           kthread+0x14e/0x180
           ret_from_fork+0x22/0x30
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&conn->lock);
                                   lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);
                                   lock(&conn->lock);
      lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);
    
     *** DEADLOCK ***
    
    Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type")
    Fixes: f764a6c2c1e4 ("Bluetooth: ISO: Add broadcast support")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bnxt: Do not read past the end of test names [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Jan 18 12:35:01 2023 -0800

    bnxt: Do not read past the end of test names
    
    [ Upstream commit d3e599c090fc6977331150c5f0a69ab8ce87da21 ]
    
    Test names were being concatenated based on a offset beyond the end of
    the first name, which tripped the buffer overflow detection logic:
    
     detected buffer overflow in strnlen
     [...]
     Call Trace:
     bnxt_ethtool_init.cold+0x18/0x18
    
    Refactor struct hwrm_selftest_qlist_output to use an actual array,
    and adjust the concatenation to use snprintf() rather than a series of
    strncat() calls.
    
    Reported-by: Niklas Cassel <Niklas.Cassel@wdc.com>
    Link: https://lore.kernel.org/lkml/Y8F%2F1w1AZTvLglFX@x1-carbon/
    Tested-by: Niklas Cassel <Niklas.Cassel@wdc.com>
    Fixes: eb51365846bc ("bnxt_en: Add basic ethtool -t selftest support.")
    Cc: Michael Chan <michael.chan@broadcom.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: netdev@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation [+ + +]
Author: Luis Gerhorst <gerhorst@cs.fau.de>
Date:   Mon Jan 9 16:05:46 2023 +0100

    bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation
    
    [ Upstream commit e4f4db47794c9f474b184ee1418f42e6a07412b6 ]
    
    To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to
    insufficient speculative store bypass mitigation") inserts lfence
    instructions after 1) initializing a stack slot and 2) spilling a
    pointer to the stack.
    
    However, this does not cover cases where a stack slot is first
    initialized with a pointer (subject to sanitization) but then
    overwritten with a scalar (not subject to sanitization because
    the slot was already initialized). In this case, the second write
    may be subject to speculative store bypass (SSB) creating a
    speculative pointer-as-scalar type confusion. This allows the
    program to subsequently leak the numerical pointer value using,
    for example, a branch-based cache side channel.
    
    To fix this, also sanitize scalars if they write a stack slot
    that previously contained a pointer. Assuming that pointer-spills
    are only generated by LLVM on register-pressure, the performance
    impact on most real-world BPF programs should be small.
    
    The following unprivileged BPF bytecode drafts a minimal exploit
    and the mitigation:
    
      [...]
      // r6 = 0 or 1 (skalar, unknown user input)
      // r7 = accessible ptr for side channel
      // r10 = frame pointer (fp), to be leaked
      //
      r9 = r10 # fp alias to encourage ssb
      *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked
      // lfence added here because of pointer spill to stack.
      //
      // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor
      // for no r9-r10 dependency.
      //
      *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr
      // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,
      // store may be subject to SSB
      //
      // fix: also add an lfence when the slot contained a ptr
      //
      r8 = *(u64 *)(r9 - 8)
      // r8 = architecturally a scalar, speculatively a ptr
      //
      // leak ptr using branch-based cache side channel:
      r8 &= 1 // choose bit to leak
      if r8 == 0 goto SLOW // no mispredict
      // architecturally dead code if input r6 is 0,
      // only executes speculatively iff ptr bit is 1
      r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)
    SLOW:
      [...]
    
    After running this, the program can time the access to *(r7 + 0) to
    determine whether the chosen pointer bit was 0 or 1. Repeat this 64
    times to recover the whole address on amd64.
    
    In summary, sanitization can only be skipped if one scalar is
    overwritten with another scalar. Scalar-confusion due to speculative
    store bypass can not lead to invalid accesses because the pointer
    bounds deducted during verification are enforced using branchless
    logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on
    pointer arithmetic") for details.
    
    Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}
    because speculative leaks are likely unexpected if these were enabled.
    For example, leaking the address to a protected log file may be acceptable
    while disabling the mitigation might unintentionally leak the address
    into the cached-state of a map that is accessible to unprivileged
    processes.
    
    Fixes: 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation")
    Signed-off-by: Luis Gerhorst <gerhorst@cs.fau.de>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Henriette Hofmeier <henriette.hofmeier@rub.de>
    Link: https://lore.kernel.org/bpf/edc95bad-aada-9cfc-ffe2-fa9bb206583c@cs.fau.de
    Link: https://lore.kernel.org/bpf/20230109150544.41465-1-gerhorst@cs.fau.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: hash map, avoid deadlock with suitable hash mask [+ + +]
Author: Tonghao Zhang <tong@infragraf.org>
Date:   Wed Jan 11 17:29:01 2023 +0800

    bpf: hash map, avoid deadlock with suitable hash mask
    
    [ Upstream commit 9f907439dc80e4a2fcfb949927b36c036468dbb3 ]
    
    The deadlock still may occur while accessed in NMI and non-NMI
    context. Because in NMI, we still may access the same bucket but with
    different map_locked index.
    
    For example, on the same CPU, .max_entries = 2, we update the hash map,
    with key = 4, while running bpf prog in NMI nmi_handle(), to update
    hash map with key = 20, so it will have the same bucket index but have
    different map_locked index.
    
    To fix this issue, using min mask to hash again.
    
    Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked")
    Signed-off-by: Tonghao Zhang <tong@infragraf.org>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Andrii Nakryiko <andrii@kernel.org>
    Cc: Martin KaFai Lau <martin.lau@linux.dev>
    Cc: Song Liu <song@kernel.org>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: Stanislav Fomichev <sdf@google.com>
    Cc: Hao Luo <haoluo@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Hou Tao <houtao1@huawei.com>
    Acked-by: Yonghong Song <yhs@fb.com>
    Acked-by: Hou Tao <houtao1@huawei.com>
    Link: https://lore.kernel.org/r/20230111092903.92389-1-tong@infragraf.org
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: zoned: enable metadata over-commit for non-ZNS setup [+ + +]
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Tue Jan 10 15:04:32 2023 +0900

    btrfs: zoned: enable metadata over-commit for non-ZNS setup
    
    [ Upstream commit 85e79ec7b78f863178ca488fd8cb5b3de6347756 ]
    
    The commit 79417d040f4f ("btrfs: zoned: disable metadata overcommit for
    zoned") disabled the metadata over-commit to track active zones properly.
    
    However, it also introduced a heavy overhead by allocating new metadata
    block groups and/or flushing dirty buffers to release the space
    reservations. Specifically, a workload (write only without any sync
    operations) worsen its performance from 343.77 MB/sec (v5.19) to 182.89
    MB/sec (v6.0).
    
    The performance is still bad on current misc-next which is 187.95 MB/sec.
    And, with this patch applied, it improves back to 326.70 MB/sec (+73.82%).
    
    This patch introduces a new fs_info->flag BTRFS_FS_NO_OVERCOMMIT to
    indicate it needs to disable the metadata over-commit. The flag is enabled
    when a device with max active zones limit is loaded into a file-system.
    
    Fixes: 79417d040f4f ("btrfs: zoned: disable metadata overcommit for zoned")
    CC: stable@vger.kernel.org # 6.0+
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: Fix oops due to uncleared server->smbd_conn in reconnect [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Jan 25 14:02:13 2023 +0000

    cifs: Fix oops due to uncleared server->smbd_conn in reconnect
    
    commit b7ab9161cf5ddc42a288edf9d1a61f3bdffe17c7 upstream.
    
    In smbd_destroy(), clear the server->smbd_conn pointer after freeing the
    smbd_connection struct that it points to so that reconnection doesn't get
    confused.
    
    Fixes: 8ef130f9ec27 ("CIFS: SMBD: Implement function to destroy a SMB Direct connection")
    Cc: stable@vger.kernel.org
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Acked-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Pavel Shilovsky <piastryyy@gmail.com>
    Cc: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: fix potential deadlock in cache_refresh_path() [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Tue Jan 17 19:00:37 2023 -0300

    cifs: fix potential deadlock in cache_refresh_path()
    
    [ Upstream commit 9fb0db40513e27537fde63287aea920b60557a69 ]
    
    Avoid getting DFS referral from an exclusive lock in
    cache_refresh_path() because the tcon IPC used for getting the
    referral could be disconnected and thus causing a deadlock as shown
    below:
    
    task A                       task B
    ======                       ======
    cifs_demultiplex_thread()    dfs_cache_find()
     cifs_handle_standard()       cache_refresh_path()
      reconnect_dfs_server()       down_write()
       dfs_cache_noreq_find()       get_dfs_referral()
        down_read() <- deadlock      smb2_get_dfs_refer()
                                      SMB2_ioctl()
                                       cifs_send_recv()
                                        compound_send_recv()
                                         wait_for_response()
    
    where task A cannot wake up task B because it is blocked on
    down_read() due to the exclusive lock held in cache_refresh_path() and
    therefore not being able to make progress.
    
    Fixes: c9f711039905 ("cifs: keep referral server sessions alive")
    Reviewed-by: Aurélien Aptel <aurelien.aptel@gmail.com>
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: fix potential memory leaks in session setup [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Tue Jan 10 20:35:46 2023 -0300

    cifs: fix potential memory leaks in session setup
    
    [ Upstream commit 2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f ]
    
    Make sure to free cifs_ses::auth_key.response before allocating it as
    we might end up leaking memory in reconnect or mounting.
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpufreq: Add SM6375 to cpufreq-dt-platdev blocklist [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Tue Jan 3 18:11:29 2023 +0100

    cpufreq: Add SM6375 to cpufreq-dt-platdev blocklist
    
    [ Upstream commit faf28e240dd118d9521c68aeb9388b9b8f02d9d0 ]
    
    The Qualcomm SM6375 platform uses the qcom-cpufreq-hw driver, so add
    it to the cpufreq-dt-platdev driver's blocklist.
    
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: Add Tegra234 to cpufreq-dt-platdev blocklist [+ + +]
Author: Sumit Gupta <sumitg@nvidia.com>
Date:   Tue Dec 20 21:32:37 2022 +0530

    cpufreq: Add Tegra234 to cpufreq-dt-platdev blocklist
    
    [ Upstream commit 01c5bb0cc2a39fbc56ff9a5ef28b79447f0c2351 ]
    
    Tegra234 platform uses the tegra194-cpufreq driver, so add it
    to the blocklist in cpufreq-dt-platdev driver to avoid the cpufreq
    driver registration from there.
    
    Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: armada-37xx: stop using 0 as NULL pointer [+ + +]
Author: Miles Chen <miles.chen@mediatek.com>
Date:   Tue Jan 10 11:12:52 2023 +0800

    cpufreq: armada-37xx: stop using 0 as NULL pointer
    
    [ Upstream commit 08f0adb193c008de640fde34a2e00a666c01d77c ]
    
    Use NULL for NULL pointer to fix the following sparse warning:
    drivers/cpufreq/armada-37xx-cpufreq.c:448:32: sparse: warning: Using plain integer as NULL pointer
    
    Signed-off-by: Miles Chen <miles.chen@mediatek.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: CPPC: Add u64 casts to avoid overflowing [+ + +]
Author: Pierre Gondois <pierre.gondois@arm.com>
Date:   Tue Dec 20 11:12:25 2022 +0100

    cpufreq: CPPC: Add u64 casts to avoid overflowing
    
    [ Upstream commit f5f94b9c8b805d87ff185caf9779c3a4d07819e3 ]
    
    The fields of the _CPC object are unsigned 32-bits values.
    To avoid overflows while using _CPC's values, add 'u64' casts.
    
    Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
device property: fix of node refcount leak in fwnode_graph_get_next_endpoint() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 23 10:25:42 2022 +0800

    device property: fix of node refcount leak in fwnode_graph_get_next_endpoint()
    
    [ Upstream commit 39af728649b05e88a2b40e714feeee6451c3f18e ]
    
    The 'parent' returned by fwnode_graph_get_port_parent()
    with refcount incremented when 'prev' is not NULL, it
    needs be put when finish using it.
    
    Because the parent is const, introduce a new variable to
    store the returned fwnode, then put it before returning
    from fwnode_graph_get_next_endpoint().
    
    Fixes: b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-and-tested-by: Daniel Scally <djrscally@gmail.com>
    Link: https://lore.kernel.org/r/20221123022542.2999510-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: Fix double increment of client_count in dma_chan_get() [+ + +]
Author: Koba Ko <koba.ko@canonical.com>
Date:   Thu Dec 1 11:00:50 2022 +0800

    dmaengine: Fix double increment of client_count in dma_chan_get()
    
    [ Upstream commit f3dc1b3b4750851a94212dba249703dd0e50bb20 ]
    
    The first time dma_chan_get() is called for a channel the channel
    client_count is incorrectly incremented twice for public channels,
    first in balance_ref_count(), and again prior to returning. This
    results in an incorrect client count which will lead to the
    channel resources not being freed when they should be. A simple
     test of repeated module load and unload of async_tx on a Dell
     Power Edge R7425 also shows this resulting in a kref underflow
     warning.
    
    [  124.329662] async_tx: api initialized (async)
    [  129.000627] async_tx: api initialized (async)
    [  130.047839] ------------[ cut here ]------------
    [  130.052472] refcount_t: underflow; use-after-free.
    [  130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28
    refcount_warn_saturate+0xba/0x110
    [  130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr
    intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm
    mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si
    syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops
    k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat
    fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul
    libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas
    i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash
    dm_log dm_mod [last unloaded: async_tx]
    [  130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not
    tainted 5.14.0-185.el9.x86_64 #1
    [  130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS
    1.18.0 01/17/2022
    [  130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110
    [  130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d
    26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a
    bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff
    48 c7
    [  130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286
    [  130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000
    [  130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0
    [  130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff
    [  130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970
    [  130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [  130.198739] FS:  00007f646435c740(0000) GS:ffff9daf9de00000(0000)
    knlGS:0000000000000000
    [  130.206832] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0
    [  130.219729] Call Trace:
    [  130.222192]  <TASK>
    [  130.224305]  dma_chan_put+0x10d/0x110
    [  130.227988]  dmaengine_put+0x7a/0xa0
    [  130.231575]  __do_sys_delete_module.constprop.0+0x178/0x280
    [  130.237157]  ? syscall_trace_enter.constprop.0+0x145/0x1d0
    [  130.242652]  do_syscall_64+0x5c/0x90
    [  130.246240]  ? exc_page_fault+0x62/0x150
    [  130.250178]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [  130.255243] RIP: 0033:0x7f6463a3f5ab
    [  130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48
    83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00
    00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89
    01 48
    [  130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:
    00000000000000b0
    [  130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab
    [  130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8
    [  130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000
    [  130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8
    [  130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8
    [  130.320875]  </TASK>
    [  130.323081] ---[ end trace eff7156d56b5cf25 ]---
    
    cat /sys/class/dma/dma0chan*/in_use would get the wrong result.
    2
    2
    2
    
    Fixes: d2f4f99db3e9 ("dmaengine: Rework dma_chan_get")
    Signed-off-by: Koba Ko <koba.ko@canonical.com>
    Reviewed-by: Jie Hai <haijie1@huawei.com>
    Test-by: Jie Hai <haijie1@huawei.com>
    Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Tested-by: Joel Savitz <jsavitz@redhat.com>
    Link: https://lore.kernel.org/r/20221201030050.978595-1-koba.ko@canonical.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: qcom: gpi: Set link_rx bit on GO TRE for rx operation [+ + +]
Author: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
Date:   Fri Dec 16 23:08:13 2022 +0530

    dmaengine: qcom: gpi: Set link_rx bit on GO TRE for rx operation
    
    [ Upstream commit 25e8ac233d24051e2c4ff64c34f60609b0988568 ]
    
    Rx operation on SPI GSI DMA is currently not working.
    As per GSI spec, link_rx bit is to be set on GO TRE on tx
    channel whenever there is going to be a DMA TRE on rx
    channel. This is currently set for duplex operation only.
    
    Set the bit for rx operation as well.
    This is part of changes required to bring up Rx.
    
    Fixes: 94b8f0e58fa1 ("dmaengine: qcom: gpi: set chain and link flag for duplex")
    Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/1671212293-14767-1-git-send-email-quic_vnivarth@quicinc.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: tegra: Fix memory leak in terminate_all() [+ + +]
Author: Akhil R <akhilrajeev@nvidia.com>
Date:   Wed Jan 18 17:28:01 2023 +0530

    dmaengine: tegra: Fix memory leak in terminate_all()
    
    [ Upstream commit a7a7ee6f5a019ad72852c001abbce50d35e992f2 ]
    
    Terminate vdesc when terminating an ongoing transfer.
    This will ensure that the vdesc is present in the desc_terminated list
    The descriptor will be freed later in desc_free_list().
    
    This fixes the memory leaks which can happen when terminating an
    ongoing transfer.
    
    Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver")
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Link: https://lore.kernel.org/r/20230118115801.15210-1-akhilrajeev@nvidia.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: k3-udma: Do conditional decrement of UDMA_CHAN_RT_PEER_BCNT_REG [+ + +]
Author: Jayesh Choudhary <j-choudhary@ti.com>
Date:   Mon Nov 28 14:20:05 2022 +0530

    dmaengine: ti: k3-udma: Do conditional decrement of UDMA_CHAN_RT_PEER_BCNT_REG
    
    [ Upstream commit efab25894a41a920d9581183741e7fadba00719c ]
    
    PSIL_EP_NATIVE endpoints may not have PEER registers for BCNT and thus
    udma_decrement_byte_counters() should not try to decrement these counters.
    This fixes the issue of crypto IPERF testing where the client side (EVM)
    hangs without transfer of packets to the server side, seen since this
    function was added.
    
    Fixes: 7c94dcfa8fcf ("dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow")
    Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/20221128085005.489964-1-j-choudhary@ti.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: xilinx_dma: call of_node_put() when breaking out of for_each_child_of_node() [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Tue Nov 22 10:16:12 2022 +0800

    dmaengine: xilinx_dma: call of_node_put() when breaking out of for_each_child_of_node()
    
    [ Upstream commit 596b53ccc36a546ab28e8897315c5b4d1d5a0200 ]
    
    Since for_each_child_of_node() will increase the refcount of node, we need
    to call of_node_put() manually when breaking out of the iteration.
    
    Fixes: 9cd4360de609 ("dma: Add Xilinx AXI Video Direct Memory Access Engine driver support")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Acked-by: Peter Korsgaard <peter@korsgaard.com>
    Link: https://lore.kernel.org/r/20221122021612.1908866-1-liushixin2@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
driver core: Fix test_async_probe_init saves device in wrong array [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Fri Nov 25 14:35:41 2022 +0800

    driver core: Fix test_async_probe_init saves device in wrong array
    
    [ Upstream commit 9be182da0a7526f1b9a3777a336f83baa2e64d23 ]
    
    In test_async_probe_init, second set of asynchronous devices are saved
    in sync_dev[sync_id], which should be async_dev[async_id].
    This makes these devices not unregistered when exit.
    
    > modprobe test_async_driver_probe && \
    > modprobe -r test_async_driver_probe && \
    > modprobe test_async_driver_probe
     ...
    > sysfs: cannot create duplicate filename '/devices/platform/test_async_driver.4'
    > kobject_add_internal failed for test_async_driver.4 with -EEXIST,
      don't try to register things with the same name in the same directory.
    
    Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Link: https://lore.kernel.org/r/20221125063541.241328-1-chenzhongjin@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: fix issues with driver unload [+ + +]
Author: Hamza Mahfooz <hamza.mahfooz@amd.com>
Date:   Tue Jan 17 15:12:49 2023 -0500

    drm/amd/display: fix issues with driver unload
    
    [ Upstream commit e433adc60f7f847e734c56246b09291532f29b6d ]
    
    Currently, we run into a number of WARN()s when attempting to unload the
    amdgpu driver (e.g. using "modprobe -r amdgpu"). These all stem from
    calling drm_encoder_cleanup() too early. So, to fix this we can stop
    calling drm_encoder_cleanup() from amdgpu_dm_fini() and instead have it
    be called from amdgpu_dm_encoder_destroy(). Also, we don't need to free
    in amdgpu_dm_encoder_destroy() since mst_encoders[] isn't explicitly
    allocated by the slab allocator.
    
    Fixes: f74367e492ba ("drm/amdgpu/display: create fake mst encoders ahead of time (v4)")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0 [+ + +]
Author: Evan Quan <evan.quan@amd.com>
Date:   Fri Jan 20 11:21:53 2023 +0800

    drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0
    
    commit 15b207d0abdcbb2271774aa99d9a290789159e75 upstream.
    
    Add SMU13.0.0 AllowIHInterrupt message mapping.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments [+ + +]
Author: Lyude Paul <lyude@redhat.com>
Date:   Wed Nov 23 14:50:16 2022 -0500

    drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments
    
    commit 1119e1f9636b76aef14068c7fd0b4d55132b86b8 upstream.
    
    Looks like I made a pretty big mistake here without noticing: it seems when
    I moved the assignments of mst_state->pbn_div I completely missed the fact
    that the reason for us calling drm_dp_mst_update_slots() earlier was to
    account for the fact that we need to call this function using info from the
    root MST connector, instead of just trying to do this from each MST
    encoder's atomic check function. Otherwise, we end up filling out all of
    DC's link information with zeroes.
    
    So, let's restore that and hopefully fix this DSC regression.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state")
    Cc: stable@vger.kernel.org # 6.1
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Tested-by: Didier Raboud <odyx@debian.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/display/mst: limit payload to be updated one by one [+ + +]
Author: Wayne Lin <Wayne.Lin@amd.com>
Date:   Fri Dec 9 19:05:33 2022 +0800

    drm/amdgpu/display/mst: limit payload to be updated one by one
    
    commit cb1e0b015f56b8f3c7f5ce33ff4b782ee5674512 upstream.
    
    [Why]
    amdgpu expects to update payload table for one stream one time
    by calling dm_helpers_dp_mst_write_payload_allocation_table().
    Currently, it get modified to try to update HW payload table
    at once by referring mst_state.
    
    [How]
    This is just a quick workaround. Should find way to remove the
    temporary struct dc_dp_mst_stream_allocation_table later if set
    struct link_mst_stream_allocatio directly is possible.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
    Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state")
    Cc: stable@vger.kernel.org # 6.1
    Acked-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Tested-by: Didier Raboud <odyx@debian.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD [+ + +]
Author: Wayne Lin <Wayne.Lin@amd.com>
Date:   Mon Dec 12 15:41:18 2022 +0800

    drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
    
    commit f85c5e25fd28fe0bf6d6d0563cf83758a4e05c8f upstream.
    
    [Why & How]
    Now the vc_start_slot is controlled at drm side. When we
    service a long HPD, we still need to run
    dm_helpers_dp_mst_write_payload_allocation_table() to update
    drm mst_mgr's relevant variable. Otherwise, on the next plug-in,
    payload will get assigned with a wrong start slot.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
    Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state")
    Cc: stable@vger.kernel.org # 6.1
    Acked-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Tested-by: Didier Raboud <odyx@debian.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: complete gfxoff allow signal during suspend without delay [+ + +]
Author: Harsh Jain <harsh.jain@amd.com>
Date:   Wed Nov 2 15:23:08 2022 +0530

    drm/amdgpu: complete gfxoff allow signal during suspend without delay
    
    commit 4b31b92b143f7d209f3d494c56d4c4673e9fc53d upstream.
    
    change guarantees that gfxoff is allowed before moving further in
    s2idle sequence to add more reliablity about gfxoff in amdgpu IP's
    suspend flow
    
    Signed-off-by: Harsh Jain <harsh.jain@amd.com>
    Reviewed-by: Evan Quan <evan.quan@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: "Limonciello, Mario" <Mario.Limonciello@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: remove unconditional trap enable on add gfx11 queues [+ + +]
Author: Jonathan Kim <jonathan.kim@amd.com>
Date:   Thu Jan 19 18:42:03 2023 -0500

    drm/amdgpu: remove unconditional trap enable on add gfx11 queues
    
    commit 2de3769830346e68b3de0f4abc0d8e2625ad9dac upstream.
    
    Rebase of driver has incorrect unconditional trap enablement
    for GFX11 when adding mes queues.
    
    Reported-by: Graham Sider <graham.sider@amd.com>
    Signed-off-by: Jonathan Kim <jonathan.kim@amd.com>
    Reviewed-by: Graham Sider <graham.sider@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org # 6.1.x
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdkfd: Add sync after creating vram bo [+ + +]
Author: Eric Huang <jinhuieric.huang@amd.com>
Date:   Mon Jan 9 14:16:42 2023 -0500

    drm/amdkfd: Add sync after creating vram bo
    
    [ Upstream commit ba029e9991d9be90a28b6a0ceb25e9a6fb348829 ]
    
    There will be data corruption on vram allocated by svm
    if the initialization is not complete and application is
    writting on the memory. Adding sync to wait for the
    initialization completion is to resolve this issue.
    
    Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU [+ + +]
Author: Eric Huang <jinhuieric.huang@amd.com>
Date:   Thu Jan 5 14:01:18 2023 -0500

    drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU
    
    [ Upstream commit a6941f89d7c6a6ba49316bbd7da2fb2f719119a7 ]
    
    The point bo->kfd_bo is NULL for queue's write pointer BO
    when creating queue on mGPU. To avoid using the pointer
    fixes the error.
    
    Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
    Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/display/dp_mst: Correct the kref of port. [+ + +]
Author: Wayne Lin <Wayne.Lin@amd.com>
Date:   Wed Dec 28 14:50:43 2022 +0800

    drm/display/dp_mst: Correct the kref of port.
    
    commit d8bf2df715bb8ac964f91fe8bf67c37c5d916463 upstream.
    
    [why & how]
    We still need to refer to port while removing payload at commit_tail.
    we should keep the kref till then to release.
    
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
    Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
    Signed-off-by: Harry Wentland <harry.wentland@amd.com>
    Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state")
    Cc: stable@vger.kernel.org # 6.1
    Acked-by: Harry Wentland <harry.wentland@amd.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Tested-by: Didier Raboud <odyx@debian.org>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/drm_vma_manager: Add drm_vma_node_allow_once() [+ + +]
Author: Nirmoy Das <nirmoy.das@intel.com>
Date:   Tue Jan 17 18:52:35 2023 +0100

    drm/drm_vma_manager: Add drm_vma_node_allow_once()
    
    [ Upstream commit 899d3a3c19ac0e5da013ce34833dccb97d19b5e4 ]
    
    Currently there is no easy way for a drm driver to safely check and allow
    drm_vma_offset_node for a drm file just once. Allow drm drivers to call
    non-refcounted version of drm_vma_node_allow() so that a driver doesn't
    need to keep track of each drm_vma_node_allow() to call subsequent
    drm_vma_node_revoke() to prevent memory leak.
    
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: David Airlie <airlied@gmail.com>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Cc: Andi Shyti <andi.shyti@linux.intel.com>
    
    Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
    Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://lore.kernel.org/r/20230117175236.22317-1-nirmoy.das@intel.com
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/selftest: fix intel_selftest_modify_policy argument types [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 17:37:29 2023 +0100

    drm/i915/selftest: fix intel_selftest_modify_policy argument types
    
    [ Upstream commit 2255bbcdc39d5b0311968f86614ae4f25fdd465d ]
    
    The definition of intel_selftest_modify_policy() does not match the
    declaration, as gcc-13 points out:
    
    drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:29:5: error: conflicting types for 'intel_selftest_modify_policy' due to enum/integer mismatch; have 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, u32)' {aka 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, unsigned int)'} [-Werror=enum-int-mismatch]
       29 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:11:
    drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h:28:5: note: previous declaration of 'intel_selftest_modify_policy' with type 'int(struct intel_engine_cs *, struct intel_selftest_saved_policy *, enum selftest_scheduler_modify)'
       28 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Change the type in the definition to match.
    
    Fixes: 617e87c05c72 ("drm/i915/selftest: Fix hangcheck self test for GuC submission")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230117163743.1003219-1-arnd@kernel.org
    (cherry picked from commit 8d7eb8ed3f83f248e01a4f548d9c500a950a2c2d)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/selftests: Unwind hugepages to drop wakeref on error [+ + +]
Author: Chris Wilson <chris.p.wilson@linux.intel.com>
Date:   Tue Jan 17 13:32:34 2023 +0100

    drm/i915/selftests: Unwind hugepages to drop wakeref on error
    
    [ Upstream commit 93eea624526fc7d070cdae463408665824075f54 ]
    
    Make sure that upon error after we have acquired the wakeref we do
    release it again.
    
    v2: add another missing "goto out_wf"(Andi).
    
    Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
    Cc: Andi Shyti <andi.shyti@linux.intel.com>
    Reviewed-by: Matthew Auld <matthew.auld@intel.com>
    Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
    Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com>
    Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230117123234.26487-1-nirmoy.das@intel.com
    (cherry picked from commit 14ec40a88210151296fff3e981c1a7196ad9bf55)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915: Allow alternate fixed modes always for eDP [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Sep 27 21:06:14 2022 +0300

    drm/i915: Allow alternate fixed modes always for eDP
    
    [ Upstream commit 55cfeecc2197de68e9cc30f77c711dcbcdf27510 ]
    
    Stop considering VBT's static DRRS support when deciding whether
    to use alternate fixed modes or not. It looks like Windows more
    or less just uses that to decide whether to automagically switch
    refresh rates on AC<->battery changes, or perhaps whether to
    even expose a control for that in some UI thing. Either way it
    seems happy to always use all EDID modes, and I guess the
    DRRS/VRR stuff more or less adjusts how said modes get
    actually used.
    
    Let's do the same and just accept all the suitable looking
    modes from EDID, whether we have DRRS or VRR.
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6323
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6484
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-3-ville.syrjala@linux.intel.com
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Allow panel fixed modes to have differing sync polarities [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Oct 20 12:39:38 2022 +0300

    drm/i915: Allow panel fixed modes to have differing sync polarities
    
    [ Upstream commit 2bd0db4b3f0bd529f75b32538fc5a3775e3591c0 ]
    
    Apparently some panels declare multiple modes with random
    sync polarities. Seems a bit weird, but looks like Windows/GOP
    doesn't care, so let follow suit and accept alternate fixed
    modes regardless of their sync polarities.
    
    v2: Don't pollute the DRM_ namespace with a define (Jani)
    
    Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6968
    Acked-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221020093938.27200-1-ville.syrjala@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/i915: Fix a memory leak with reused mmap_offset [+ + +]
Author: Nirmoy Das <nirmoy.das@intel.com>
Date:   Tue Jan 17 18:52:36 2023 +0100

    drm/i915: Fix a memory leak with reused mmap_offset
    
    [ Upstream commit 0220e4fe178c3390eb0291cdb34912d66972db8a ]
    
    drm_vma_node_allow() and drm_vma_node_revoke() should be called in
    balanced pairs. We call drm_vma_node_allow() once per-file everytime a
    user calls mmap_offset, but only call drm_vma_node_revoke once per-file
    on each mmap_offset. As the mmap_offset is reused by the client, the
    per-file vm_count may remain non-zero and the rbtree leaked.
    
    Call drm_vma_node_allow_once() instead to prevent that memory leak.
    
    Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
    Cc: Andi Shyti <andi.shyti@linux.intel.com>
    
    Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
    Fixes: 786555987207 ("drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list")
    Reported-by: Chuansheng Liu <chuansheng.liu@intel.com>
    Reported-by: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://lore.kernel.org/r/20230117175236.22317-2-nirmoy.das@intel.com
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/a6xx: Avoid gx gbit halt during rpm suspend [+ + +]
Author: Akhil P Oommen <quic_akhilpo@quicinc.com>
Date:   Fri Dec 16 22:33:14 2022 +0530

    drm/msm/a6xx: Avoid gx gbit halt during rpm suspend
    
    [ Upstream commit f4a75b5933c998e60fd812a7680e0971eb1c7cee ]
    
    As per the downstream driver, gx gbif halt is required only during
    recovery sequence. So lets avoid it during regular rpm suspend.
    
    Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/515279/
    Link: https://lore.kernel.org/r/20221216223253.1.Ice9c47bfeb1fddb8dc377a3491a043a3ee7fca7d@changeid
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/gpu: Fix potential double-free [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Tue Jan 10 13:28:59 2023 -0800

    drm/msm/gpu: Fix potential double-free
    
    [ Upstream commit a66f1efcf748febea7758c4c3c8b5bc5294949ef ]
    
    If userspace was calling the MSM_SET_PARAM ioctl on multiple threads to
    set the COMM or CMDLINE param, it could trigger a race causing the
    previous value to be kfree'd multiple times.  Fix this by serializing on
    the gpu lock.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Fixes: d4726d770068 ("drm/msm: Add a way to override processes comm/cmdline")
    Patchwork: https://patchwork.freedesktop.org/patch/517778/
    Link: https://lore.kernel.org/r/20230110212903.1925878-1-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panfrost: fix GENERIC_ATOMIC64 dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 17 17:44:43 2023 +0100

    drm/panfrost: fix GENERIC_ATOMIC64 dependency
    
    [ Upstream commit 6437a549ae178a3f5a5c03e983f291ebcdc2bbc7 ]
    
    On ARMv5 and earlier, a randconfig build can still run into
    
    WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE
      Depends on [n]: IOMMU_SUPPORT [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y]) && !GENERIC_ATOMIC64 [=y]
      Selected by [y]:
      - DRM_PANFROST [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARM [=y] || ARM64 || COMPILE_TEST [=y] && !GENERIC_ATOMIC64 [=y]) && MMU [=y]
    
    Rework the dependencies to always require a working cmpxchg64.
    
    Fixes: db594ba3fcf9 ("drm/panfrost: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Steven Price <steven.price@arm.com>
    Signed-off-by: Steven Price <steven.price@arm.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230117164456.1591901-1-arnd@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vc4: bo: Fix drmm_mutex_init memory hog [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Thu Jan 12 10:12:43 2023 +0100

    drm/vc4: bo: Fix drmm_mutex_init memory hog
    
    [ Upstream commit 07a2975c65f2be2e22591d795a9c39b00f95fd11 ]
    
    Commit 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") converted,
    among other functions, vc4_create_object() to use drmm_mutex_init().
    
    However, that function is used to allocate a BO, and therefore the
    mutex needs to be freed much sooner than when the DRM device is removed
    from the system.
    
    For each buffer allocation we thus end up allocating a small structure
    as part of the DRM-managed mechanism that is never freed, eventually
    leading us to no longer having any free memory anymore.
    
    Let's switch back to mutex_init/mutex_destroy to deal with it properly.
    
    Fixes: 374146cad469 ("drm/vc4: Switch to drmm_mutex_init")
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230112091243.490799-1-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vc4: bo: Fix unused variable warning [+ + +]
Author: Maxime Ripard <maxime@cerno.tech>
Date:   Fri Jan 13 16:46:37 2023 +0100

    drm/vc4: bo: Fix unused variable warning
    
    [ Upstream commit 83a7f8e4899fb4cd77c787a3373f3e82b49a080f ]
    
    Commit 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog")
    removed the only use of the ret variable, but didn't remove the
    variable itself leading to a unused variable warning.
    
    Remove that variable.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Fixes: 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog")
    Reviewed-by: Maíra Canal <mcanal@igalia.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230113154637.1704116-1-maxime@cerno.tech
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm: Add orientation quirk for Lenovo ideapad D330-10IGL [+ + +]
Author: Patrick Thompson <ptf@google.com>
Date:   Tue Dec 20 15:58:26 2022 -0500

    drm: Add orientation quirk for Lenovo ideapad D330-10IGL
    
    [ Upstream commit 0688773f0710528e1ab302c3d6317e269f2e2e6e ]
    
    Panel is 800x1280 but mounted on a detachable form factor sideways.
    
    Signed-off-by: Patrick Thompson <ptf@google.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221220205826.178008-1-ptf@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dt-bindings: i2c: renesas,rzv2m: Fix SoC specific string [+ + +]
Author: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Date:   Tue Jan 17 17:50:17 2023 +0000

    dt-bindings: i2c: renesas,rzv2m: Fix SoC specific string
    
    commit 0a4eecf96c640886226f1ca7fdbb11bb20bc55b9 upstream.
    
    The preferred form for Renesas' compatible strings is:
    "<vendor>,<family>-<module>"
    
    Somehow the compatible string for the r9a09g011 I2C IP was upstreamed
    as renesas,i2c-r9a09g011 instead of renesas,r9a09g011-i2c, which
    is really confusing, especially considering the generic fallback
    is renesas,rzv2m-i2c.
    
    The first user of renesas,i2c-r9a09g011 in the kernel is not yet in
    a kernel release, it will be in v6.1, therefore it can still be
    fixed in v6.1.
    Even if we don't fix it before v6.2, I don't think there is any
    harm in making such a change.
    
    s/renesas,i2c-r9a09g011/renesas,r9a09g011-i2c/g for consistency.
    
    Fixes: ba7a4d15e2c4 ("dt-bindings: i2c: Document RZ/V2M I2C controller")
    Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: riscv: fix single letter canonical order [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Mon Dec 5 17:45:00 2022 +0000

    dt-bindings: riscv: fix single letter canonical order
    
    commit a943385aa80151c6b2611d3a1cf8338af2b257a1 upstream.
    
    I used the wikipedia table for ordering extensions when updating the
    pattern here in commit 299824e68bd0 ("dt-bindings: riscv: add new
    riscv,isa strings for emulators").
    
    Unfortunately that table did not match canonical order, as defined by
    the RISC-V ISA Manual, which defines extension ordering in (what is
    currently) Table 41, "Standard ISA extension names". Fix things up by
    re-sorting v (vector) and adding p (packed-simd) & j (dynamic
    languages). The e (reduced integer) and g (general) extensions are still
    intentionally left out.
    
    Link: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-unpriv-pdf-from-asciidoc-15112022 # Chapter 29.5
    Fixes: 299824e68bd0 ("dt-bindings: riscv: add new riscv,isa strings for emulators")
    Acked-by: Guo Ren <guoren@kernel.org>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
    Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20221205174459.60195-3-conor@kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: riscv: fix underscore requirement for multi-letter extensions [+ + +]
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Mon Dec 5 17:44:59 2022 +0000

    dt-bindings: riscv: fix underscore requirement for multi-letter extensions
    
    commit ec64efc4966edf19fa1bc398a26bddfbadc1605f upstream.
    
    The RISC-V ISA Manual allows the first multi-letter extension to avoid
    a leading underscore. Underscores are only required between multi-letter
    extensions.
    
    The dt-binding does not validate that a multi-letter extension is
    canonically ordered, as that'd need an even worse regex than is here,
    but it should not fail validation for valid ISA strings.
    
    Allow the first multi-letter extension to appear immediately after
    the single-letter extensions.
    
    Link: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-unpriv-pdf-from-asciidoc-15112022 # Chapter 29.5
    Fixes: 299824e68bd0 ("dt-bindings: riscv: add new riscv,isa strings for emulators")
    Acked-by: Guo Ren <guoren@kernel.org>
    Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
    Acked-by: Rob Herring <robh@kernel.org>
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
    Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
    Link: https://lore.kernel.org/r/20221205174459.60195-2-conor@kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/device: Respect any driver-supplied workqueue polling value [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Wed Jan 18 20:38:48 2023 +0530

    EDAC/device: Respect any driver-supplied workqueue polling value
    
    commit cec669ff716cc83505c77b242aecf6f7baad869d upstream.
    
    The EDAC drivers may optionally pass the poll_msec value. Use that value
    if available, else fall back to 1000ms.
    
      [ bp: Touchups. ]
    
    Fixes: e27e3dac6517 ("drivers/edac: add edac_device class")
    Reported-by: Luca Weiss <luca.weiss@fairphone.com>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
    Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
    Cc: <stable@vger.kernel.org> # 4.9
    Link: https://lore.kernel.org/r/COZYL8MWN97H.MROQ391BGA09@otso
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/highbank: Fix memory leak in highbank_mc_probe() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Dec 29 09:48:24 2022 +0400

    EDAC/highbank: Fix memory leak in highbank_mc_probe()
    
    [ Upstream commit e7a293658c20a7945014570e1921bf7d25d68a36 ]
    
    When devres_open_group() fails, it returns -ENOMEM without freeing memory
    allocated by edac_mc_alloc().
    
    Call edac_mc_free() on the error handling path to avoid a memory leak.
    
      [ bp: Massage commit message. ]
    
    Fixes: a1b01edb2745 ("edac: add support for Calxeda highbank memory controller")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Link: https://lore.kernel.org/r/20221229054825.1361993-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Wed Jan 18 20:38:50 2023 +0530

    EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info
    
    commit 977c6ba624f24ae20cf0faee871257a39348d4a9 upstream.
    
    The memory for llcc_driv_data is allocated by the LLCC driver. But when
    it is passed as the private driver info to the EDAC core, it will get freed
    during the qcom_edac driver release. So when the qcom_edac driver gets probed
    again, it will try to use the freed data leading to the use-after-free bug.
    
    Hence, do not pass llcc_driv_data as pvt_info but rather reference it
    using the platform_data pointer in the qcom_edac driver.
    
    Fixes: 27450653f1db ("drivers: edac: Add EDAC driver support for QCOM SoCs")
    Reported-by: Steev Klimaszewski <steev@kali.org>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Tested-by: Steev Klimaszewski <steev@kali.org> # Thinkpad X13s
    Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
    Cc: <stable@vger.kernel.org> # 4.20
    Link: https://lore.kernel.org/r/20230118150904.26913-4-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
erofs: fix kvcalloc() misuse with __GFP_NOFAIL [+ + +]
Author: Gao Xiang <xiang@kernel.org>
Date:   Tue Jan 10 15:49:27 2023 +0800

    erofs: fix kvcalloc() misuse with __GFP_NOFAIL
    
    [ Upstream commit 12724ba38992bd045e92a9a88a868a530f89d13e ]
    
    As reported by syzbot [1], kvcalloc() cannot work with  __GFP_NOFAIL.
    Let's use kcalloc() instead.
    
    [1] https://lore.kernel.org/r/0000000000007796bd05f1852ec2@google.com
    
    Reported-by: syzbot+c3729cda01706a04fb98@syzkaller.appspotmail.com
    Fixes: fe3e5914e6dc ("erofs: try to leave (de)compressed_pages on stack if possible")
    Fixes: 4f05687fd703 ("erofs: introduce struct z_erofs_decompress_backend")
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Link: https://lore.kernel.org/r/20230110074927.41651-1-hsiangkao@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: arm_scmi: Fix virtio channels cleanup on shutdown [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Thu Dec 22 18:38:23 2022 +0000

    firmware: arm_scmi: Fix virtio channels cleanup on shutdown
    
    [ Upstream commit e325285de2cd82fbdcc4df8898e4c6a597674816 ]
    
    When unloading the SCMI core stack module, configured to use the virtio
    SCMI transport, LOCKDEP reports the splat down below about unsafe locks
    dependencies.
    
    In order to avoid this possible unsafe locking scenario call upfront
    virtio_break_device() before getting hold of vioch->lock.
    
    =====================================================
     WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
     6.1.0-00067-g6b934395ba07-dirty #4 Not tainted
     -----------------------------------------------------
     rmmod/307 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
     ffff000080c510e0 (&dev->vqs_list_lock){+.+.}-{3:3}, at: virtio_break_device+0x28/0x68
    
     and this task is already holding:
     ffff00008288ada0 (&channels[i].lock){-.-.}-{3:3}, at: virtio_chan_free+0x60/0x168 [scmi_module]
    
     which would create a new lock dependency:
      (&channels[i].lock){-.-.}-{3:3} -> (&dev->vqs_list_lock){+.+.}-{3:3}
    
     but this new dependency connects a HARDIRQ-irq-safe lock:
      (&channels[i].lock){-.-.}-{3:3}
    
     ... which became HARDIRQ-irq-safe at:
       lock_acquire+0x128/0x398
       _raw_spin_lock_irqsave+0x78/0x140
       scmi_vio_complete_cb+0xb4/0x3b8 [scmi_module]
       vring_interrupt+0x84/0x120
       vm_interrupt+0x94/0xe8
       __handle_irq_event_percpu+0xb4/0x3d8
       handle_irq_event_percpu+0x20/0x68
       handle_irq_event+0x50/0xb0
       handle_fasteoi_irq+0xac/0x138
       generic_handle_domain_irq+0x34/0x50
       gic_handle_irq+0xa0/0xd8
       call_on_irq_stack+0x2c/0x54
       do_interrupt_handler+0x8c/0x90
       el1_interrupt+0x40/0x78
       el1h_64_irq_handler+0x18/0x28
       el1h_64_irq+0x64/0x68
       _raw_write_unlock_irq+0x48/0x80
       ep_start_scan+0xf0/0x128
       do_epoll_wait+0x390/0x858
       do_compat_epoll_pwait.part.34+0x1c/0xb8
       __arm64_sys_epoll_pwait+0x80/0xd0
       invoke_syscall+0x4c/0x110
       el0_svc_common.constprop.3+0x98/0x120
       do_el0_svc+0x34/0xd0
       el0_svc+0x40/0x98
       el0t_64_sync_handler+0x98/0xc0
       el0t_64_sync+0x170/0x174
    
     to a HARDIRQ-irq-unsafe lock:
      (&dev->vqs_list_lock){+.+.}-{3:3}
    
     ... which became HARDIRQ-irq-unsafe at:
     ...
       lock_acquire+0x128/0x398
       _raw_spin_lock+0x58/0x70
       __vring_new_virtqueue+0x130/0x1c0
       vring_create_virtqueue+0xc4/0x2b8
       vm_find_vqs+0x20c/0x430
       init_vq+0x308/0x390
       virtblk_probe+0x114/0x9b0
       virtio_dev_probe+0x1a4/0x248
       really_probe+0xc8/0x3a8
       __driver_probe_device+0x84/0x190
       driver_probe_device+0x44/0x110
       __driver_attach+0x104/0x1e8
       bus_for_each_dev+0x7c/0xd0
       driver_attach+0x2c/0x38
       bus_add_driver+0x1e4/0x258
       driver_register+0x6c/0x128
       register_virtio_driver+0x2c/0x48
       virtio_blk_init+0x70/0xac
       do_one_initcall+0x84/0x420
       kernel_init_freeable+0x2d0/0x340
       kernel_init+0x2c/0x138
       ret_from_fork+0x10/0x20
    
     other info that might help us debug this:
    
      Possible interrupt unsafe locking scenario:
    
            CPU0                    CPU1
            ----                    ----
       lock(&dev->vqs_list_lock);
                                    local_irq_disable();
                                    lock(&channels[i].lock);
                                    lock(&dev->vqs_list_lock);
       <Interrupt>
         lock(&channels[i].lock);
    
      *** DEADLOCK ***
    ================
    
    Fixes: 42e90eb53bf3f ("firmware: arm_scmi: Add a virtio channel refcount")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20221222183823.518856-6-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: arm_scmi: Harden shared memory access in fetch_notification [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Thu Dec 22 18:38:21 2022 +0000

    firmware: arm_scmi: Harden shared memory access in fetch_notification
    
    [ Upstream commit 9bae076cd4e3e3c3dc185cae829d80b2dddec86e ]
    
    A misbheaving SCMI platform firmware could reply with out-of-spec
    notifications, shorter than the mimimum size comprising a header.
    
    Fixes: d5141f37c42e ("firmware: arm_scmi: Add notifications support in transport layer")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20221222183823.518856-4-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: arm_scmi: Harden shared memory access in fetch_response [+ + +]
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Thu Dec 22 18:38:20 2022 +0000

    firmware: arm_scmi: Harden shared memory access in fetch_response
    
    [ Upstream commit ad78b81a1077f7d956952cd8bdfe1e61504e3eb8 ]
    
    A misbheaving SCMI platform firmware could reply with out-of-spec messages,
    shorter than the mimimum size comprising a header and a status field.
    
    Harden shmem_fetch_response to properly truncate such a bad messages.
    
    Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Link: https://lore.kernel.org/r/20221222183823.518856-3-cristian.marussi@arm.com
    Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

firmware: coreboot: Check size of table entry and use flex-array [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Jan 12 15:03:16 2023 -0800

    firmware: coreboot: Check size of table entry and use flex-array
    
    [ Upstream commit 3b293487b8752cc42c1cbf8a0447bc6076c075fa ]
    
    The memcpy() of the data following a coreboot_table_entry couldn't
    be evaluated by the compiler under CONFIG_FORTIFY_SOURCE. To make it
    easier to reason about, add an explicit flexible array member to struct
    coreboot_device so the entire entry can be copied at once. Additionally,
    validate the sizes before copying. Avoids this run-time false positive
    warning:
    
      memcpy: detected field-spanning write (size 168) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:103 (size 8)
    
    Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Link: https://lore.kernel.org/all/03ae2704-8c30-f9f0-215b-7cdf4ad35a9a@molgen.mpg.de/
    Cc: Jack Rosenthal <jrosenth@chromium.org>
    Cc: Guenter Roeck <groeck@chromium.org>
    Cc: Julius Werner <jwerner@chromium.org>
    Cc: Brian Norris <briannorris@chromium.org>
    Cc: Stephen Boyd <swboyd@chromium.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Julius Werner <jwerner@chromium.org>
    Reviewed-by: Guenter Roeck <groeck@chromium.org>
    Link: https://lore.kernel.org/r/20230107031406.gonna.761-kees@kernel.org
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
    Link: https://lore.kernel.org/r/20230112230312.give.446-kees@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Fix up more non-executable files marked executable [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jan 28 11:17:57 2023 -0800

    Fix up more non-executable files marked executable
    
    [ Upstream commit c96618275234ad03d44eafe9f8844305bb44fda4 ]
    
    Joe found another DT file that shouldn't be executable, and that
    frustrated me enough that I went hunting with this script:
    
        git ls-files -s |
            grep '^100755' |
            cut -f2 |
            xargs grep -L '^#!'
    
    and that found another file that shouldn't have been marked executable
    either, despite being in the scripts directory.
    
    Maybe these two are the last ones at least for now.  But I'm sure we'll
    be back in a few years, fixing things up again.
    
    Fixes: 8c6789f4e2d4 ("ASoC: dt-bindings: Add Everest ES8326 audio CODEC")
    Fixes: 4d8e5cd233db ("locking/atomics: Fix scripts/atomic/ script permissions")
    Reported-by: Joe Perches <joe@perches.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ftrace/scripts: Update the instructions for ftrace-bisect.sh [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Mon Jan 23 11:22:52 2023 -0500

    ftrace/scripts: Update the instructions for ftrace-bisect.sh
    
    commit 7ae4ba7195b1bac04a4210a499da9d8c63b0ba9c upstream.
    
    The instructions for the ftrace-bisect.sh script, which is used to find
    what function is being traced that is causing a kernel crash, and possibly
    a triple fault reboot, uses the old method. In 5.1, a new feature was
    added that let the user write in the index into available_filter_functions
    that maps to the function a user wants to set in set_ftrace_filter (or
    set_ftrace_notrace). This takes O(1) to set, as suppose to writing a
    function name, which takes O(n) (where n is the number of functions in
    available_filter_functions).
    
    The ftrace-bisect.sh requires setting half of the functions in
    available_filter_functions, which is O(n^2) using the name method to enable
    and can take several minutes to complete. The number method is O(n) which
    takes less than a second to complete. Using the number method for any
    kernel 5.1 and after is the proper way to do the bisect.
    
    Update the usage to reflect the new change, as well as using the
    /sys/kernel/tracing path instead of the obsolete debugfs path.
    
    Link: https://lkml.kernel.org/r/20230123112252.022003dd@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: f79b3f338564e ("ftrace: Allow enabling of filters via index of available_filter_functions")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ftrace: Export ftrace_free_filter() to modules [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jan 3 12:49:11 2023 +0000

    ftrace: Export ftrace_free_filter() to modules
    
    commit 8be9fbd5345da52f4a74f7f81d55ff9fa0a2958e upstream.
    
    Setting filters on an ftrace ops results in some memory being allocated
    for the filter hashes, which must be freed before the ops can be freed.
    This can be done by removing every individual element of the hash by
    calling ftrace_set_filter_ip() or ftrace_set_filter_ips() with `remove`
    set, but this is somewhat error prone as it's easy to forget to remove
    an element.
    
    Make it easier to clean this up by exporting ftrace_free_filter(), which
    can be used to clean up all of the filter hashes after an ftrace_ops has
    been unregistered.
    
    Using this, fix the ftrace-direct* samples to free hashes prior to being
    unloaded. All other code either removes individual filters explicitly or
    is built-in and already calls ftrace_free_filter().
    
    Link: https://lkml.kernel.org/r/20230103124912.2948963-3-mark.rutland@arm.com
    
    Cc: stable@vger.kernel.org
    Cc: Florent Revest <revest@chromium.org>
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: e1067a07cfbc ("ftrace/samples: Add module to test multi direct modify interface")
    Fixes: 5fae941b9a6f ("ftrace/samples: Add multi direct interface test module")
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
gpio: ep93xx: Fix port F hwirq numbers in handler [+ + +]
Author: Nikita Shubin <nikita.shubin@maquefel.me>
Date:   Wed Jan 25 11:30:24 2023 +0300

    gpio: ep93xx: Fix port F hwirq numbers in handler
    
    [ Upstream commit 0f04cdbdb210000a97c773b28b598fa8ac3aafa4 ]
    
    Fix wrong translation of irq numbers in port F handler, as ep93xx hwirqs
    increased by 1, we should simply decrease them by 1 in translation.
    
    Fixes: 482c27273f52 ("ARM: ep93xx: renumber interrupts")
    Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: mxc: Always set GPIOs used as interrupt source to INPUT mode [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Jan 16 10:49:57 2023 +0100

    gpio: mxc: Always set GPIOs used as interrupt source to INPUT mode
    
    [ Upstream commit 8e88a0feebb241cab0253698b2f7358b6ebec802 ]
    
    Always configure GPIO pins which are used as interrupt source as INPUTs.
    In case the default pin configuration is OUTPUT, or the prior stage does
    configure the pins as OUTPUT, then Linux will not reconfigure the pin as
    INPUT and no interrupts are received.
    
    Always configure the interrupt source GPIO pin as input to fix the above case.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Fixes: 07bd1a6cc7cbb ("MXC arch: Add gpio support for the whole platform")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: mxc: Protect GPIO irqchip RMW with bgpio spinlock [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Mon Jan 16 10:49:56 2023 +0100

    gpio: mxc: Protect GPIO irqchip RMW with bgpio spinlock
    
    [ Upstream commit e5464277625c1aca5c002e0f470377cdd6816dcf ]
    
    The driver currently performs register read-modify-write without locking
    in its irqchip part, this could lead to a race condition when configuring
    interrupt mode setting. Add the missing bgpio spinlock lock/unlock around
    the register read-modify-write.
    
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Marc Zyngier <maz@kernel.org>
    Fixes: 07bd1a6cc7cbb ("MXC arch: Add gpio support for the whole platform")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gpio: mxc: Unlock on error path in mxc_flip_edge() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Jan 24 18:20:26 2023 +0300

    gpio: mxc: Unlock on error path in mxc_flip_edge()
    
    [ Upstream commit 37870358616ca7fdb1e90ad1cdd791655ec54414 ]
    
    We recently added locking to this function but one error path was
    over looked.  Drop the lock before returning.
    
    Fixes: e5464277625c ("gpio: mxc: Protect GPIO irqchip RMW with bgpio spinlock")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Acked-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: amd_sfh: Fix warning unwind goto [+ + +]
Author: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Date:   Mon Jan 2 22:00:42 2023 +0530

    HID: amd_sfh: Fix warning unwind goto
    
    [ Upstream commit 2a33ad4a0ba5a527b92aeef9a313aefec197fe28 ]
    
    Return directly instead of using existing goto will not cleanup
    previously allocated resources. Hence replace return with goto
    to fix warning unwind goto which cleanups previously allocated
    resources.
    
    Fixes: 93ce5e0231d7 ("HID: amd_sfh: Implement SFH1.1 functionality")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: betop: check shape of output reports [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Wed Jan 11 18:12:16 2023 +0000

    HID: betop: check shape of output reports
    
    [ Upstream commit 3782c0d6edf658b71354a64d60aa7a296188fc90 ]
    
    betopff_init() only checks the total sum of the report counts for each
    report field to be at least 4, but hid_betopff_play() expects 4 report
    fields.
    A device advertising an output report with one field and 4 report counts
    would pass the check but crash the kernel with a NULL pointer dereference
    in hid_betopff_play().
    
    Fixes: 52cd7785f3cd ("HID: betop: add drivers/hid/hid-betopff.c")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: check empty report_list in bigben_probe() [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Mon Jan 16 11:11:25 2023 +0000

    HID: check empty report_list in bigben_probe()
    
    [ Upstream commit c7bf714f875531f227f2ef1fdcc8f4d44e7c7d9d ]
    
    Add a check for empty report_list in bigben_probe().
    The missing check causes a type confusion when issuing a list_entry()
    on an empty report_list.
    The problem is caused by the assumption that the device must
    have valid report_list. While this will be true for all normal HID
    devices, a suitably malicious device can violate the assumption.
    
    Fixes: 256a90ed9e46 ("HID: hid-bigbenff: driver for BigBen Interactive PS3OFMINIPAD gamepad")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: check empty report_list in hid_validate_values() [+ + +]
Author: Pietro Borrello <borrello@diag.uniroma1.it>
Date:   Mon Jan 16 11:11:24 2023 +0000

    HID: check empty report_list in hid_validate_values()
    
    [ Upstream commit b12fece4c64857e5fab4290bf01b2e0317a88456 ]
    
    Add a check for empty report_list in hid_validate_values().
    The missing check causes a type confusion when issuing a list_entry()
    on an empty report_list.
    The problem is caused by the assumption that the device must
    have valid report_list. While this will be true for all normal HID
    devices, a suitably malicious device can violate the assumption.
    
    Fixes: 1b15d2e5b807 ("HID: core: fix validation of report id 0")
    Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: intel_ish-hid: Add check for ishtp_dma_tx_map [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Nov 22 21:48:23 2022 +0800

    HID: intel_ish-hid: Add check for ishtp_dma_tx_map
    
    [ Upstream commit b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8 ]
    
    As the kcalloc may return NULL pointer,
    it should be better to check the ishtp_dma_tx_map
    before use in order to avoid NULL pointer dereference.
    
    Fixes: 3703f53b99e4 ("HID: intel_ish-hid: ISH Transport layer")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: revert CHERRY_MOUSE_000C quirk [+ + +]
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Jan 17 15:41:40 2023 +0100

    HID: revert CHERRY_MOUSE_000C quirk
    
    [ Upstream commit cbf44580ce6b310272a73e3e794233fd064330bd ]
    
    This partially reverts commit f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk
    for some mice"), as it turns out to break reboot on some platforms for reason
    yet to be understood.
    
    Fixes: f6d910a89a2391 ("HID: usbhid: Add ALWAYS_POLL quirk for some mice")
    Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: designware: Fix unbalanced suspended flag [+ + +]
Author: Richard Fitzgerald <rf@opensource.cirrus.com>
Date:   Mon Dec 19 13:01:45 2022 +0000

    i2c: designware: Fix unbalanced suspended flag
    
    [ Upstream commit 75507a319876aba88932e2c7dab58b6c22d89f6b ]
    
    Ensure that i2c_mark_adapter_suspended() is always balanced by a call to
    i2c_mark_adapter_resumed().
    
    dw_i2c_plat_resume() must always be called, so that
    i2c_mark_adapter_resumed() is called. This is not compatible with
    DPM_FLAG_MAY_SKIP_RESUME, so remove the flag.
    
    Since the controller is always resumed on system resume the
    dw_i2c_plat_complete() callback is redundant and has been removed.
    
    The unbalanced suspended flag was introduced by commit c57813b8b288
    ("i2c: designware: Lock the adapter while setting the suspended flag")
    
    Before that commit, the system and runtime PM used the same functions. The
    DPM_FLAG_MAY_SKIP_RESUME was used to skip the system resume if the driver
    had been in runtime-suspend. If system resume was skipped, the suspended
    flag would be cleared by the next runtime resume. The check of the
    suspended flag was _after_ the call to pm_runtime_get_sync() in
    i2c_dw_xfer(). So either a system resume or a runtime resume would clear
    the flag before it was checked.
    
    Having introduced the unbalanced suspended flag with that commit, a further
    commit 80704a84a9f8
    ("i2c: designware: Use the i2c_mark_adapter_suspended/resumed() helpers")
    
    changed from using a local suspended flag to using the
    i2c_mark_adapter_suspended/resumed() functions. These use a flag that is
    checked by I2C core code before issuing the transfer to the bus driver, so
    there was no opportunity for the bus driver to runtime resume itself before
    the flag check.
    
    Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
    Fixes: c57813b8b288 ("i2c: designware: Lock the adapter while setting the suspended flag")
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: designware: use casting of u64 in clock multiplication to avoid overflow [+ + +]
Author: Lareine Khawaly <lareine@amazon.com>
Date:   Wed Dec 21 19:59:00 2022 +0000

    i2c: designware: use casting of u64 in clock multiplication to avoid overflow
    
    [ Upstream commit c8c37bc514514999e62a17e95160ed9ebf75ca8d ]
    
    In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow
    by depending on the values of the given parameters including the ic_clk.
    For example in our use case where ic_clk is larger than one million,
    multiplication of ic_clk * 4700 will result in 32 bit overflow.
    
    Add cast of u64 to the calculation to avoid multiplication overflow, and
    use the corresponding define for divide.
    
    Fixes: 2373f6b9744d ("i2c-designware: split of i2c-designware.c into core and bus specific parts")
    Signed-off-by: Lareine Khawaly <lareine@amazon.com>
    Signed-off-by: Hanna Hawa <hhhawa@amazon.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iavf: fix temporary deadlock and failure to set MAC address [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Thu Dec 15 23:50:48 2022 +0100

    iavf: fix temporary deadlock and failure to set MAC address
    
    [ Upstream commit 4411a608f7c8df000cb1a9f7881982dd8e10839a ]
    
    We are seeing an issue where setting the MAC address on iavf fails with
    EAGAIN after the 2.5s timeout expires in iavf_set_mac().
    
    There is the following deadlock scenario:
    
    iavf_set_mac(), holding rtnl_lock, waits on:
      iavf_watchdog_task (within iavf_wq) to send a message to the PF,
     and
      iavf_adminq_task (within iavf_wq) to receive a response from the PF.
    In this adapter state (>=__IAVF_DOWN), these tasks do not need to take
    rtnl_lock, but iavf_wq is a global single-threaded workqueue, so they
    may get stuck waiting for another adapter's iavf_watchdog_task to run
    iavf_init_config_adapter(), which does take rtnl_lock.
    
    The deadlock resolves itself by the timeout in iavf_set_mac(),
    which results in EAGAIN returned to userspace.
    
    Let's break the deadlock loop by changing iavf_wq into a per-adapter
    workqueue, so that one adapter's tasks are not blocked by another's.
    
    Fixes: 35a2443d0910 ("iavf: Add waiting for response from PF in set mac")
    Co-developed-by: Ivan Vecera <ivecera@redhat.com>
    Signed-off-by: Ivan Vecera <ivecera@redhat.com>
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iavf: schedule watchdog immediately when changing primary MAC [+ + +]
Author: Stefan Assmann <sassmann@kpanic.de>
Date:   Tue Jan 10 09:00:18 2023 +0100

    iavf: schedule watchdog immediately when changing primary MAC
    
    [ Upstream commit e2b53ea5a7c1fb484277ad12cd075f502cf03b04 ]
    
    iavf_replace_primary_mac() utilizes queue_work() to schedule the
    watchdog task but that only ensures that the watchdog task is queued
    to run. To make sure the watchdog is executed asap use
    mod_delayed_work().
    
    Without this patch it may take up to 2s until the watchdog task gets
    executed, which may cause long delays when setting the MAC address.
    
    Fixes: a3e839d539e0 ("iavf: Add usage of new virtchnl format to set default MAC")
    Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
    Reviewed-by: Michal Schmidt <mschmidt@redhat.com>
    Tested-by: Michal Schmidt <mschmidt@redhat.com>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/hfi1: Fix expected receive setup error exit issues [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:21 2023 -0500

    IB/hfi1: Fix expected receive setup error exit issues
    
    [ Upstream commit e0c4a422f5246abefbf7c178ef99a1f2dc3c5f62 ]
    
    Fix three error exit issues in expected receive setup.
    Re-arrange error exits to increase readability.
    
    Issues and fixes:
    1. Possible missed page unpin if tidlist copyout fails and
       not all pinned pages where made part of a TID.
       Fix: Unpin the unused pages.
    
    2. Return success with unset return values tidcnt and length
       when no pages were pinned.
       Fix: Return -ENOSPC if no pages were pinned.
    
    3. Return success with unset return values tidcnt and length when
       no rcvarray entries available.
       Fix: Return -ENOSPC if no rcvarray entries are available.
    
    Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
    Fixes: 97736f36dbeb ("IB/hfi1: Validate page aligned for a given virtual addres")
    Fixes: f404ca4c7ea8 ("IB/hfi1: Refactor hfi_user_exp_rcv_setup() IOCTL")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328548150.1472310.1492305874804187634.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Immediately remove invalid memory from hardware [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:26 2023 -0500

    IB/hfi1: Immediately remove invalid memory from hardware
    
    [ Upstream commit 1c7edde1b5720ddb0aff5ca8c7f605a0f92526eb ]
    
    When a user expected receive page is unmapped, it should be
    immediately removed from hardware rather than depend on a
    reaction from user space.
    
    Fixes: 2677a7680e77 ("IB/hfi1: Fix memory leak during unexpected shutdown")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328548663.1472310.7871808081861622659.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Reject a zero-length user expected buffer [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:11 2023 -0500

    IB/hfi1: Reject a zero-length user expected buffer
    
    [ Upstream commit 0a0a6e80472c98947d73c3d13bcd7d101895f55d ]
    
    A zero length user buffer makes no sense and the code
    does not handle it correctly.  Instead, reject a
    zero length as invalid.
    
    Fixes: 97736f36dbeb ("IB/hfi1: Validate page aligned for a given virtual addres")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328547120.1472310.6362802432127399257.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Remove user expected buffer invalidate race [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:31 2023 -0500

    IB/hfi1: Remove user expected buffer invalidate race
    
    [ Upstream commit b3deec25847bda34e34d5d7be02f633caf000bd8 ]
    
    During setup, there is a possible race between a page invalidate
    and hardware programming.  Add a covering invalidate over the user
    target range during setup.  If anything within that range is
    invalidated during setup, fail the setup.  Once set up, each
    TID will have its own invalidate callback and invalidate.
    
    Fixes: 3889551db212 ("RDMA/hfi1: Use mmu_interval_notifier_insert for user_exp_rcv")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328549178.1472310.9867497376936699488.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

IB/hfi1: Reserve user expected TIDs [+ + +]
Author: Dean Luick <dean.luick@cornelisnetworks.com>
Date:   Mon Jan 9 12:31:16 2023 -0500

    IB/hfi1: Reserve user expected TIDs
    
    [ Upstream commit ecf91551cdd2925ed6d9a9d99074fa5f67b90596 ]
    
    To avoid a race, reserve the number of user expected
    TIDs before setup.
    
    Fixes: 7e7a436ecb6e ("staging/hfi1: Add TID entry program function body")
    Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Link: https://lore.kernel.org/r/167328547636.1472310.7419712824785353905.stgit@awfm-02.cornelisnetworks.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: i8042 - add Clevo PCX0DX to i8042 quirk table [+ + +]
Author: Werner Sembach <wse@tuxedocomputers.com>
Date:   Tue Jan 10 14:45:24 2023 +0100

    Input: i8042 - add Clevo PCX0DX to i8042 quirk table
    
    commit 9c445d2637c938a800fcc8b5f0b10e60c94460c7 upstream.
    
    The Clevo PCX0DX/TUXEDO XP1511, need quirks for the keyboard to not be
    occasionally unresponsive after resume.
    
    Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
    Link: https://lore.kernel.org/r/20230110134524.553620-1-wse@tuxedocomputers.com
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
interconnect: qcom: msm8996: Fix regmap max_register values [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Dec 10 21:03:51 2022 +0100

    interconnect: qcom: msm8996: Fix regmap max_register values
    
    [ Upstream commit 4be39d5d86c690c60e2afe55787fc5ec4409d0f0 ]
    
    The device tree reg starts at BUS_BASE + QoS_OFFSET, but the regmap
    configs in the ICC driver had values suggesting the reg started at
    BUS_BASE. Shrink them down (where they haven't been already, so for
    providers where QoS_OFFSET = 0) to make sure they stay within their
    window.
    
    Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #db820c
    Link: https://lore.kernel.org/r/20221210200353.418391-4-konrad.dybcio@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

interconnect: qcom: msm8996: Provide UFS clocks to A2NoC [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Sat Dec 10 21:03:50 2022 +0100

    interconnect: qcom: msm8996: Provide UFS clocks to A2NoC
    
    [ Upstream commit 60426ff08af6a21275d9c879c0dfb09406469868 ]
    
    On eMMC devices the bootloader has no business enabling UFS clocks.
    That results in a platform hang and hard reboot when trying to vote
    on paths including MASTER_UFS and since sync_state guarantees that
    it's done at boot time, this effectively prevents such devices from
    booting. Fix that.
    
    Fixes: 7add937f5222 ("interconnect: qcom: Add MSM8996 interconnect provider driver")
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> #db820c
    Link: https://lore.kernel.org/r/20221210200353.418391-3-konrad.dybcio@linaro.org
    Signed-off-by: Georgi Djakov <djakov@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring/msg_ring: fix remote queue to disabled ring [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Fri Jan 20 16:38:06 2023 +0000

    io_uring/msg_ring: fix remote queue to disabled ring
    
    commit 8579538c89e33ce78be2feb41e07489c8cbf8f31 upstream.
    
    IORING_SETUP_R_DISABLED rings don't have the submitter task set, so
    it's not always safe to use ->submitter_task. Disallow posting msg_ring
    messaged to disabled rings. Also add task NULL check for loosy sync
    around testing for IORING_SETUP_R_DISABLED.
    
    Cc: stable@vger.kernel.org
    Fixes: 6d043ee1164ca ("io_uring: do msg_ring in target task via tw")
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring/net: cache provided buffer group value for multishot receives [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Sun Jan 22 10:02:55 2023 -0700

    io_uring/net: cache provided buffer group value for multishot receives
    
    commit b00c51ef8f72ced0965d021a291b98ff822c5337 upstream.
    
    If we're using ring provided buffers with multishot receive, and we end
    up doing an io-wq based issue at some points that also needs to select
    a buffer, we'll lose the initially assigned buffer group as
    io_ring_buffer_select() correctly clears the buffer group list as the
    issue isn't serialized by the ctx uring_lock. This is fine for normal
    receives as the request puts the buffer and finishes, but for multishot,
    we will re-arm and do further receives. On the next trigger for this
    multishot receive, the receive will try and pick from a buffer group
    whose value is the same as the buffer ID of the las receive. That is
    obviously incorrect, and will result in a premature -ENOUFS error for
    the receive even if we had available buffers in the correct group.
    
    Cache the buffer group value at prep time, so we can restore it for
    future receives. This only needs doing for the above mentioned case, but
    just do it by default to keep it easier to read.
    
    Cc: stable@vger.kernel.org
    Fixes: b3fdea6ecb55 ("io_uring: multishot recv")
    Fixes: 9bb66906f23e ("io_uring: support multishot in recvmsg")
    Cc: Dylan Yudaken <dylany@meta.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
io_uring: always prep_async for drain requests [+ + +]
Author: Dylan Yudaken <dylany@meta.com>
Date:   Fri Jan 27 02:59:11 2023 -0800

    io_uring: always prep_async for drain requests
    
    [ Upstream commit ef5c600adb1d985513d2b612cc90403a148ff287 ]
    
    Drain requests all go through io_drain_req, which has a quick exit in case
    there is nothing pending (ie the drain is not useful). In that case it can
    run the issue the request immediately.
    
    However for safety it queues it through task work.
    The problem is that in this case the request is run asynchronously, but
    the async work has not been prepared through io_req_prep_async.
    
    This has not been a problem up to now, as the task work always would run
    before returning to userspace, and so the user would not have a chance to
    race with it.
    
    However - with IORING_SETUP_DEFER_TASKRUN - this is no longer the case and
    the work might be defered, giving userspace a chance to change data being
    referred to in the request.
    
    Instead _always_ prep_async for drain requests, which is simpler anyway
    and removes this issue.
    
    Cc: stable@vger.kernel.org
    Fixes: c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN")
    Signed-off-by: Dylan Yudaken <dylany@meta.com>
    Link: https://lore.kernel.org/r/20230127105911.2420061-1-dylany@meta.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: hold locks for io_req_complete_failed [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Nov 23 11:33:37 2022 +0000

    io_uring: hold locks for io_req_complete_failed
    
    [ Upstream commit e276ae344a770f91912a81c6a338d92efd319be2 ]
    
    A preparation patch, make sure we always hold uring_lock around
    io_req_complete_failed(). The only place deviating from the rule
    is io_cancel_defer_files(), queue a tw instead.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/70760344eadaecf2939287084b9d4ba5c05a6984.1669203009.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: inline __io_req_complete_post() [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Thu Nov 17 18:41:06 2022 +0000

    io_uring: inline __io_req_complete_post()
    
    [ Upstream commit f9d567c75ec216447f36da6e855500023504fa04 ]
    
    There is only one user of __io_req_complete_post(), inline it.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/ef4c9059950a3da5cf68df00f977f1fd13bd9306.1668597569.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: inline __io_req_complete_put() [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Nov 23 11:33:40 2022 +0000

    io_uring: inline __io_req_complete_put()
    
    [ Upstream commit fa18fa2272c7469e470dcb7bf838ea50a25494ca ]
    
    Inline __io_req_complete_put() into io_req_complete_post(), there are no
    other users.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/1923a4dfe80fa877f859a22ed3df2d5fc8ecf02b.1669203009.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: inline io_req_task_work_add() [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Fri Nov 11 16:54:08 2022 +0000

    io_uring: inline io_req_task_work_add()
    
    [ Upstream commit e52d2e583e4ad1d5d0b804d79c2b8752eb0e5ceb ]
    
    __io_req_task_work_add() is huge but marked inline, that makes compilers
    to generate lots of garbage. Inline the wrapper caller
    io_req_task_work_add() instead.
    
    before and after:
       text    data     bss     dec     hex filename
      47347   16248       8   63603    f873 io_uring/io_uring.o
       text    data     bss     dec     hex filename
      45303   16248       8   61559    f077 io_uring/io_uring.o
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/26dc8c28ca0160e3269ef3e55c5a8b917c4d4450.1668162751.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: remove io_req_tw_post_queue [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Nov 23 11:33:39 2022 +0000

    io_uring: remove io_req_tw_post_queue
    
    [ Upstream commit 833b5dfffc26c81835ce38e2a5df9ac5fa142735 ]
    
    Remove io_req_tw_post() and io_req_tw_post_queue(), we can use
    io_req_task_complete() instead.
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/b9b73c08022c7f1457023ac841f35c0100e70345.1669203009.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

io_uring: use io_req_task_complete() in timeout [+ + +]
Author: Pavel Begunkov <asml.silence@gmail.com>
Date:   Wed Nov 23 11:33:38 2022 +0000

    io_uring: use io_req_task_complete() in timeout
    
    [ Upstream commit 624fd779fd869bdcb2c0ccca0f09456eed71ed52 ]
    
    Use a more generic io_req_task_complete() in timeout completion
    task_work instead of io_req_complete_post().
    
    Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
    Link: https://lore.kernel.org/r/bda1710b58c07bf06107421c2a65c529ea9cdcac.1669203009.git.asml.silence@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: ef5c600adb1d ("io_uring: always prep_async for drain requests")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv4: prevent potential spectre v1 gadget in fib_metrics_match() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 13:31:40 2023 +0000

    ipv4: prevent potential spectre v1 gadget in fib_metrics_match()
    
    [ Upstream commit 5e9398a26a92fc402d82ce1f97cc67d832527da0 ]
    
    if (!type)
            continue;
        if (type > RTAX_MAX)
            return false;
        ...
        fi_val = fi->fib_metrics->metrics[type - 1];
    
    @type being used as an array index, we need to prevent
    cpu speculation or risk leaking kernel memory content.
    
    Fixes: 5f9ae3d9e7e4 ("ipv4: do metrics match when looking up and deleting a route")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230120133140.3624204-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv4: prevent potential spectre v1 gadget in ip_metrics_convert() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 13:30:40 2023 +0000

    ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()
    
    [ Upstream commit 1d1d63b612801b3f0a39b7d4467cad0abd60e5c8 ]
    
    if (!type)
                    continue;
            if (type > RTAX_MAX)
                    return -EINVAL;
            ...
            metrics[type - 1] = val;
    
    @type being used as an array index, we need to prevent
    cpu speculation or risk leaking kernel memory content.
    
    Fixes: 6cf9dfd3bd62 ("net: fib: move metrics parsing to a helper")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230120133040.3623463-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: fix reachability confirmation with proxy_ndp [+ + +]
Author: Gergely Risko <gergely.risko@gmail.com>
Date:   Thu Jan 19 14:40:41 2023 +0100

    ipv6: fix reachability confirmation with proxy_ndp
    
    commit 9f535c870e493841ac7be390610ff2edec755762 upstream.
    
    When proxying IPv6 NDP requests, the adverts to the initial multicast
    solicits are correct and working.  On the other hand, when later a
    reachability confirmation is requested (on unicast), no reply is sent.
    
    This causes the neighbor entry expiring on the sending node, which is
    mostly a non-issue, as a new multicast request is sent.  There are
    routers, where the multicast requests are intentionally delayed, and in
    these environments the current implementation causes periodic packet
    loss for the proxied endpoints.
    
    The root cause is the erroneous decrease of the hop limit, as this
    is checked in ndisc.c and no answer is generated when it's 254 instead
    of the correct 255.
    
    Cc: stable@vger.kernel.org
    Fixes: 46c7655f0b56 ("ipv6: decrease hop limit counter in ip6_forward()")
    Signed-off-by: Gergely Risko <gergely.risko@gmail.com>
    Tested-by: Gergely Risko <gergely.risko@gmail.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kbuild: export top-level LDFLAGS_vmlinux only to scripts/Makefile.vmlinux [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Mon Jan 9 04:23:17 2023 +0900

    kbuild: export top-level LDFLAGS_vmlinux only to scripts/Makefile.vmlinux
    
    [ Upstream commit 8debed3efe3a731451ad9a91a7a74eeb18a7f7eb ]
    
    Nathan Chancellor reports that $(NM) emits an error message when
    GNU Make 4.4 is used to build the ARM zImage.
    
      $ make-4.4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=build defconfig zImage
        [snip]
        LD      vmlinux
        NM      System.map
        SORTTAB vmlinux
        OBJCOPY arch/arm/boot/Image
        Kernel: arch/arm/boot/Image is ready
      arm-linux-gnueabi-nm: 'arch/arm/boot/compressed/../../../../vmlinux': No such file
      /bin/sh: 1: arithmetic expression: expecting primary: " "
        LDS     arch/arm/boot/compressed/vmlinux.lds
        AS      arch/arm/boot/compressed/head.o
        GZIP    arch/arm/boot/compressed/piggy_data
        AS      arch/arm/boot/compressed/piggy.o
        CC      arch/arm/boot/compressed/misc.o
    
    This occurs since GNU Make commit 98da874c4303 ("[SV 10593] Export
    variables to $(shell ...) commands"), and the O= option is needed to
    reproduce it. The generated zImage is correct despite the error message.
    
    As the commit description of 98da874c4303 [1] says, exported variables
    are passed down to $(shell ) functions, which means exported recursive
    variables might be expanded earlier than before, in the parse stage.
    
    The following test code demonstrates the change for GNU Make 4.4.
    
    [Test Makefile]
    
      $(shell echo hello > foo)
      export foo = $(shell cat bar/../foo)
      $(shell mkdir bar)
    
      all:
              @echo $(foo)
    
    [GNU Make 4.3]
    
      $ rm -rf bar; make-4.3
      hello
    
    [GNU Make 4.4]
    
      $ rm -rf bar; make-4.4
      cat: bar/../foo: No such file or directory
      hello
    
    The 'foo' is a resursively expanded (i.e. lazily expanded) variable.
    
    GNU Make 4.3 expands 'foo' just before running the recipe '@echo $(foo)',
    at this point, the directory 'bar' exists.
    
    GNU Make 4.4 expands 'foo' to evaluate $(shell mkdir bar) because it is
    exported. At this point, the directory 'bar' does not exit yet. The cat
    command cannot resolve the bar/../foo path, hence the error message.
    
    Let's get back to the kernel Makefile.
    
    In arch/arm/boot/compressed/Makefile, KBSS_SZ is referenced by
    LDFLAGS_vmlinux, which is recursive and also exported by the top
    Makefile.
    
    GNU Make 4.3 expands KBSS_SZ just before running the recipes, so no
    error message.
    
    GNU Make 4.4 expands KBSS_SZ in the parse stage, where the directory
    arm/arm/boot/compressed does not exit yet. When compiled with O=,
    the output directory is created by $(shell mkdir -p $(obj-dirs))
    in scripts/Makefile.build.
    
    There are two ways to fix this particular issue:
    
     - change "$(obj)/../../../../vmlinux" in KBSS_SZ to "vmlinux"
     - unexport LDFLAGS_vmlinux
    
    This commit takes the latter course because it is what I originally
    intended.
    
    Commit 3ec8a5b33dea ("kbuild: do not export LDFLAGS_vmlinux")
    unexported LDFLAGS_vmlinux.
    
    Commit 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its
    prerequisite is updated") accidentally exported it again.
    
    We can clean up arch/arm/boot/compressed/Makefile later.
    
    [1]: https://git.savannah.gnu.org/cgit/make.git/commit/?id=98da874c43035a490cdca81331724f233a3d0c9a
    
    Link: https://lore.kernel.org/all/Y7i8+EjwdnhHtlrr@dev-arch.thelio-3990X/
    Fixes: 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its prerequisite is updated")
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

kbuild: fix 'make modules' error when CONFIG_DEBUG_INFO_BTF_MODULES=y [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Tue Jan 10 14:48:00 2023 +0900

    kbuild: fix 'make modules' error when CONFIG_DEBUG_INFO_BTF_MODULES=y
    
    [ Upstream commit 74d3320f6f7cf72de88a7e8df573821f6db90239 ]
    
    When CONFIG_DEBUG_INFO_BTF_MODULES=y, running 'make modules'
    in the clean kernel tree will get the following error.
    
      $ grep CONFIG_DEBUG_INFO_BTF_MODULES .config
      CONFIG_DEBUG_INFO_BTF_MODULES=y
      $ make -s clean
      $ make modules
        [snip]
        AR      vmlinux.a
      ar: ./built-in.a: No such file or directory
      make: *** [Makefile:1241: vmlinux.a] Error 1
    
    'modules' depends on 'vmlinux', but builtin objects are not built.
    
    Define KBUILD_BUILTIN.
    
    Fixes: f73edc8951b2 ("kbuild: unify two modpost invocations")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kcsan: test: don't put the expect array on the stack [+ + +]
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Dec 22 23:28:21 2022 -0800

    kcsan: test: don't put the expect array on the stack
    
    [ Upstream commit 5b24ac2dfd3eb3e36f794af3aa7f2828b19035bd ]
    
    Size of the 'expect' array in the __report_matches is 1536 bytes, which
    is exactly the default frame size warning limit of the xtensa
    architecture.
    As a result allmodconfig xtensa kernel builds with the gcc that does not
    support the compiler plugins (which otherwise would push the said
    warning limit to 2K) fail with the following message:
    
      kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes
        is larger than 1536 bytes
    
    Fix it by dynamically allocating the 'expect' array.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Reviewed-by: Marco Elver <elver@google.com>
    Tested-by: Marco Elver <elver@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ksmbd: add max connections parameter [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Thu Dec 29 18:33:25 2022 +0900

    ksmbd: add max connections parameter
    
    commit 0d0d4680db22eda1eea785c47bbf66a9b33a8b16 upstream.
    
    Add max connections parameter to limit number of maximum simultaneous
    connections.
    
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Cc: stable@vger.kernel.org
    Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: do not sign response to session request for guest login [+ + +]
Author: Marios Makassikis <mmakassikis@freebox.fr>
Date:   Wed Jan 11 17:39:02 2023 +0100

    ksmbd: do not sign response to session request for guest login
    
    commit 5fde3c21cf33830eda7bfd006dc7f4bf07ec9fe6 upstream.
    
    If ksmbd.mountd is configured to assign unknown users to the guest account
    ("map to guest = bad user" in the config), ksmbd signs the response.
    
    This is wrong according to MS-SMB2 3.3.5.5.3:
       12. If the SMB2_SESSION_FLAG_IS_GUEST bit is not set in the SessionFlags
       field, and Session.IsAnonymous is FALSE, the server MUST sign the
       final session setup response before sending it to the client, as
       follows:
        [...]
    
    This fixes libsmb2 based applications failing to establish a session
    ("Wrong signature in received").
    
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Cc: stable@vger.kernel.org
    Signed-off-by: Marios Makassikis <mmakassikis@freebox.fr>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: downgrade ndr version error message to debug [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed Jan 25 00:09:02 2023 +0900

    ksmbd: downgrade ndr version error message to debug
    
    commit a34dc4a9b9e2fb3a45c179a60bb0b26539c96189 upstream.
    
    When user switch samba to ksmbd, The following message flood is coming
    when accessing files. Samba seems to changs dos attribute version to v5.
    This patch downgrade ndr version error message to debug.
    
    $ dmesg
    ...
    [68971.766914] ksmbd: v5 version is not supported
    [68971.779808] ksmbd: v5 version is not supported
    [68971.871544] ksmbd: v5 version is not supported
    [68971.910135] ksmbd: v5 version is not supported
    ...
    
    Cc: stable@vger.kernel.org
    Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ksmbd: limit pdu length size according to connection status [+ + +]
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Wed Jan 25 00:13:20 2023 +0900

    ksmbd: limit pdu length size according to connection status
    
    commit 62c487b53a7ff31e322cf2874d3796b8202c54a5 upstream.
    
    Stream protocol length will never be larger than 16KB until session setup.
    After session setup, the size of requests will not be larger than
    16KB + SMB2 MAX WRITE size. This patch limits these invalidly oversized
    requests and closes the connection immediately.
    
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Cc: stable@vger.kernel.org
    Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18259
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
kvm/vfio: Fix potential deadlock on vfio group_lock [+ + +]
Author: Yi Liu <yi.l.liu@intel.com>
Date:   Fri Jan 20 07:05:28 2023 -0800

    kvm/vfio: Fix potential deadlock on vfio group_lock
    
    [ Upstream commit 51cdc8bc120ef6e42f6fb758341f5d91bc955952 ]
    
    Currently it is possible that the final put of a KVM reference comes from
    vfio during its device close operation.  This occurs while the vfio group
    lock is held; however, if the vfio device is still in the kvm device list,
    then the following call chain could result in a deadlock:
    
    VFIO holds group->group_lock/group_rwsem
      -> kvm_put_kvm
       -> kvm_destroy_vm
        -> kvm_destroy_devices
         -> kvm_vfio_destroy
          -> kvm_vfio_file_set_kvm
           -> vfio_file_set_kvm
            -> try to hold group->group_lock/group_rwsem
    
    The key function is the kvm_destroy_devices() which triggers destroy cb
    of kvm_device_ops. It calls back to vfio and try to hold group_lock. So
    if this path doesn't call back to vfio, this dead lock would be fixed.
    Actually, there is a way for it. KVM provides another point to free the
    kvm-vfio device which is the point when the device file descriptor is
    closed. This can be achieved by providing the release cb instead of the
    destroy cb. Also rename kvm_vfio_destroy() to be kvm_vfio_release().
    
            /*
             * Destroy is responsible for freeing dev.
             *
             * Destroy may be called before or after destructors are called
             * on emulated I/O regions, depending on whether a reference is
             * held by a vcpu or other kvm component that gets destroyed
             * after the emulated I/O.
             */
            void (*destroy)(struct kvm_device *dev);
    
            /*
             * Release is an alternative method to free the device. It is
             * called when the device file descriptor is closed. Once
             * release is called, the destroy method will not be called
             * anymore as the device is removed from the device list of
             * the VM. kvm->lock is held.
             */
            void (*release)(struct kvm_device *dev);
    
    Fixes: 421cfe6596f6 ("vfio: remove VFIO_GROUP_NOTIFY_SET_KVM")
    Reported-by: Alex Williamson <alex.williamson@redhat.com>
    Suggested-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Yi Liu <yi.l.liu@intel.com>
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230114000351.115444-1-mjrosato@linux.ibm.com
    Link: https://lore.kernel.org/r/20230120150528.471752-1-yi.l.liu@intel.com
    [aw: update comment as well, s/destroy/release/]
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: GICv4.1: Fix race with doorbell on VPE activation/deactivation [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Thu Jan 19 11:07:59 2023 +0000

    KVM: arm64: GICv4.1: Fix race with doorbell on VPE activation/deactivation
    
    commit ef3691683d7bfd0a2acf48812e4ffe894f10bfa8 upstream.
    
    To save the vgic LPI pending state with GICv4.1, the VPEs must all be
    unmapped from the ITSs so that the sGIC caches can be flushed.
    The opposite is done once the state is saved.
    
    This is all done by using the activate/deactivate irqdomain callbacks
    directly from the vgic code. Crutially, this is done without holding
    the irqdesc lock for the interrupts that represent the VPE. And these
    callbacks are changing the state of the irqdesc. What could possibly
    go wrong?
    
    If a doorbell fires while we are messing with the irqdesc state,
    it will acquire the lock and change the interrupt state concurrently.
    Since we don't hole the lock, curruption occurs in on the interrupt
    state. Oh well.
    
    While acquiring the lock would fix this (and this was Shanker's
    initial approach), this is still a layering violation we could do
    without. A better approach is actually to free the VPE interrupt,
    do what we have to do, and re-request it.
    
    It is more work, but this usually happens only once in the lifetime
    of the VM and we don't really care about this sort of overhead.
    
    Fixes: f66b7b151e00 ("KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables")
    Reported-by: Shanker Donthineni <sdonthineni@nvidia.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230118022348.4137094-1-sdonthineni@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: s390: interrupt: use READ_ONCE() before cmpxchg() [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jan 9 15:54:56 2023 +0100

    KVM: s390: interrupt: use READ_ONCE() before cmpxchg()
    
    [ Upstream commit 42400d99e9f0728c17240edb9645637ead40f6b9 ]
    
    Use READ_ONCE() before cmpxchg() to prevent that the compiler generates
    code that fetches the to be compared old value several times from memory.
    
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Link: https://lore.kernel.org/r/20230109145456.2895385-1-hca@linux.ibm.com
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86/vmx: Do not skip segment attributes if unusable bit is set [+ + +]
Author: Hendrik Borghorst <hborghor@amazon.de>
Date:   Mon Nov 14 16:48:23 2022 +0000

    KVM: x86/vmx: Do not skip segment attributes if unusable bit is set
    
    commit a44b331614e6f7e63902ed7dff7adc8c85edd8bc upstream.
    
    When serializing and deserializing kvm_sregs, attributes of the segment
    descriptors are stored by user space. For unusable segments,
    vmx_segment_access_rights skips all attributes and sets them to 0.
    
    This means we zero out the DPL (Descriptor Privilege Level) for unusable
    entries.
    
    Unusable segments are - contrary to their name - usable in 64bit mode and
    are used by guests to for example create a linear map through the
    NULL selector.
    
    VMENTER checks if SS.DPL is correct depending on the CS segment type.
    For types 9 (Execute Only) and 11 (Execute Read), CS.DPL must be equal to
    SS.DPL [1].
    
    We have seen real world guests setting CS to a usable segment with DPL=3
    and SS to an unusable segment with DPL=3. Once we go through an sregs
    get/set cycle, SS.DPL turns to 0. This causes the virtual machine to crash
    reproducibly.
    
    This commit changes the attribute logic to always preserve attributes for
    unusable segments. According to [2] SS.DPL is always saved on VM exits,
    regardless of the unusable bit so user space applications should have saved
    the information on serialization correctly.
    
    [3] specifies that besides SS.DPL the rest of the attributes of the
    descriptors are undefined after VM entry if unusable bit is set. So, there
    should be no harm in setting them all to the previous state.
    
    [1] Intel SDM Vol 3C 26.3.1.2 Checks on Guest Segment Registers
    [2] Intel SDM Vol 3C 27.3.2 Saving Segment Registers and Descriptor-Table
    Registers
    [3] Intel SDM Vol 3C 26.3.2.2 Loading Guest Segment Registers and
    Descriptor-Table Registers
    
    Cc: Alexander Graf <graf@amazon.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Hendrik Borghorst <hborghor@amazon.de>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: Alexander Graf <graf@amazon.com>
    Message-Id: <20221114164823.69555-1-hborghor@amazon.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
l2tp: close all race conditions in l2tp_tunnel_register() [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Fri Jan 13 19:01:37 2023 -0800

    l2tp: close all race conditions in l2tp_tunnel_register()
    
    [ Upstream commit 0b2c59720e65885a394a017d0cf9cab118914682 ]
    
    The code in l2tp_tunnel_register() is racy in several ways:
    
    1. It modifies the tunnel socket _after_ publishing it.
    
    2. It calls setup_udp_tunnel_sock() on an existing socket without
       locking.
    
    3. It changes sock lock class on fly, which triggers many syzbot
       reports.
    
    This patch amends all of them by moving socket initialization code
    before publishing and under sock lock. As suggested by Jakub, the
    l2tp lockdep class is not necessary as we can just switch to
    bh_lock_sock_nested().
    
    Fixes: 37159ef2c1ae ("l2tp: fix a lockdep splat")
    Fixes: 6b9f34239b00 ("l2tp: fix races in tunnel creation")
    Reported-by: syzbot+52866e24647f9a23403f@syzkaller.appspotmail.com
    Reported-by: syzbot+94cc2a66fc228b23f360@syzkaller.appspotmail.com
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Guillaume Nault <gnault@redhat.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Tom Parkin <tparkin@katalix.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: convert l2tp_tunnel_list to idr [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Fri Jan 13 19:01:36 2023 -0800

    l2tp: convert l2tp_tunnel_list to idr
    
    [ Upstream commit c4d48a58f32c5972174a1d01c33b296fe378cce0 ]
    
    l2tp uses l2tp_tunnel_list to track all registered tunnels and
    to allocate tunnel ID's. IDR can do the same job.
    
    More importantly, with IDR we can hold the ID before a successful
    registration so that we don't need to worry about late error
    handling, it is not easy to rollback socket changes.
    
    This is a preparation for the following fix.
    
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Cc: Guillaume Nault <gnault@redhat.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Tom Parkin <tparkin@katalix.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

l2tp: prevent lockdep issue in l2tp_tunnel_register() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Jan 17 11:01:31 2023 +0000

    l2tp: prevent lockdep issue in l2tp_tunnel_register()
    
    [ Upstream commit b9fb10d131b8c84af9bb14e2078d5c63600c7dea ]
    
    lockdep complains with the following lock/unlock sequence:
    
         lock_sock(sk);
         write_lock_bh(&sk->sk_callback_lock);
    [1]  release_sock(sk);
    [2]  write_unlock_bh(&sk->sk_callback_lock);
    
    We need to swap [1] and [2] to fix this issue.
    
    Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
    Reported-by: syzbot+bbd35b345c7cab0d9a08@syzkaller.appspotmail.com
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/netdev/20230114030137.672706-1-xiyou.wangcong@gmail.com/T/#m1164ff20628671b0f326a24cb106ab3239c70ce3
    Cc: Cong Wang <cong.wang@bytedance.com>
    Cc: Guillaume Nault <gnault@redhat.com>
    Reviewed-by: Guillaume Nault <gnault@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 6.1.9 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 1 08:38:58 2023 +0100

    Linux 6.1.9
    
    Link: https://lore.kernel.org/r/20230130134336.532886729@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20230130181611.883327545@linuxfoundation.org
    Tested-by: Conor Dooley <conor.dooley@microchip.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Link: https://lore.kernel.org/r/20230131072621.746783417@linuxfoundation.org
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
    Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Allen Pais <apais@linux.microsoft.com>
    Tested-by: Fenil Jain <fkjainco@gmail.com>
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
lockref: stop doing cpu_relax in the cmpxchg loop [+ + +]
Author: Mateusz Guzik <mjguzik@gmail.com>
Date:   Fri Jan 13 19:44:47 2023 +0100

    lockref: stop doing cpu_relax in the cmpxchg loop
    
    [ Upstream commit f5fe24ef17b5fbe6db49534163e77499fb10ae8c ]
    
    On the x86-64 architecture even a failing cmpxchg grants exclusive
    access to the cacheline, making it preferable to retry the failed op
    immediately instead of stalling with the pause instruction.
    
    To illustrate the impact, below are benchmark results obtained by
    running various will-it-scale tests on top of the 6.2-rc3 kernel and
    Cascade Lake (2 sockets * 24 cores * 2 threads) CPU.
    
    All results in ops/s.  Note there is some variance in re-runs, but the
    code is consistently faster when contention is present.
    
      open3 ("Same file open/close"):
      proc          stock       no-pause
         1         805603         814942       (+%1)
         2        1054980        1054781       (-0%)
         8        1544802        1822858      (+18%)
        24        1191064        2199665      (+84%)
        48         851582        1469860      (+72%)
        96         609481        1427170     (+134%)
    
      fstat2 ("Same file fstat"):
      proc          stock       no-pause
         1        3013872        3047636       (+1%)
         2        4284687        4400421       (+2%)
         8        3257721        5530156      (+69%)
        24        2239819        5466127     (+144%)
        48        1701072        5256609     (+209%)
        96        1269157        6649326     (+423%)
    
    Additionally, a kernel with a private patch to help access() scalability:
    access2 ("Same file access"):
    
      proc          stock        patched      patched
                                             +nopause
        24        2378041        2005501      5370335  (-15% / +125%)
    
    That is, fixing the problems in access itself *reduces* scalability
    after the cacheline ping-pong only happens in lockref with the pause
    instruction.
    
    Note that fstat and access benchmarks are not currently integrated into
    will-it-scale, but interested parties can find them in pull requests to
    said project.
    
    Code at hand has a rather tortured history.  First modification showed
    up in commit d472d9d98b46 ("lockref: Relax in cmpxchg loop"), written
    with Itanium in mind.  Later it got patched up to use an arch-dependent
    macro to stop doing it on s390 where it caused a significant regression.
    Said macro had undergone revisions and was ultimately eliminated later,
    going back to cpu_relax.
    
    While I intended to only remove cpu_relax for x86-64, I got the
    following comment from Linus:
    
        I would actually prefer just removing it entirely and see if
        somebody else hollers. You have the numbers to prove it hurts on
        real hardware, and I don't think we have any numbers to the
        contrary.
    
        So I think it's better to trust the numbers and remove it as a
        failure, than say "let's just remove it on x86-64 and leave
        everybody else with the potentially broken code"
    
    Additionally, Will Deacon (maintainer of the arm64 port, one of the
    architectures previously benchmarked):
    
        So, from the arm64 side of the fence, I'm perfectly happy just
        removing the cpu_relax() calls from lockref.
    
    As such, come back full circle in history and whack it altogether.
    
    Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
    Link: https://lore.kernel.org/all/CAGudoHHx0Nqg6DE70zAVA75eV-HXfWyhVMWZ-aSeOofkA_=WdA@mail.gmail.com/
    Acked-by: Tony Luck <tony.luck@intel.com> # ia64
    Acked-by: Nicholas Piggin <npiggin@gmail.com> # powerpc
    Acked-by: Will Deacon <will@kernel.org> # arm64
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Fri Nov 25 15:37:57 2022 +0800

    memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe()
    
    [ Upstream commit 340cb392a038cf70540a4cdf2e98a247c66b6df4 ]
    
    The clk_disable_unprepare() should be called in the error handling
    of caps->has_mpddr_clk, fix it by replacing devm_clk_get and
    clk_prepare_enable by devm_clk_get_enabled.
    
    Fixes: e81b6abebc87 ("memory: add a driver for atmel ram controllers")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221125073757.3535219-1-cuigaosheng1@huawei.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memory: mvebu-devbus: Fix missing clk_disable_unprepare in mvebu_devbus_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Sat Nov 26 12:49:11 2022 +0800

    memory: mvebu-devbus: Fix missing clk_disable_unprepare in mvebu_devbus_probe()
    
    [ Upstream commit cb8fd6f75775165390ededea8799b60d93d9fe3e ]
    
    The clk_disable_unprepare() should be called in the error handling
    of devbus_get_timing_params() and of_platform_populate(), fix it by
    replacing devm_clk_get and clk_prepare_enable by devm_clk_get_enabled.
    
    Fixes: e81b6abebc87 ("memory: add a driver for atmel ram controllers")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221126044911.7226-1-cuigaosheng1@huawei.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memory: tegra: Remove clients SID override programming [+ + +]
Author: Ashish Mhetre <amhetre@nvidia.com>
Date:   Fri Nov 25 09:37:52 2022 +0530

    memory: tegra: Remove clients SID override programming
    
    [ Upstream commit ef86b2c2807f41c045e5534d8513a8b83f63bc39 ]
    
    On newer Tegra releases, early boot SID override programming and SID
    override programming during resume is handled by bootloader.
    In the function tegra186_mc_program_sid() which is getting removed, SID
    override register of all clients is written without checking if secure
    firmware has allowed write on it or not. If write is disabled by secure
    firmware then it can lead to errors coming from secure firmware and hang
    in kernel boot.
    Also, SID override is programmed on-demand during probe_finalize() call
    of IOMMU which is done in tegra186_mc_client_sid_override() in this same
    file. This function does it correctly by checking if write is permitted
    on SID override register. It also checks if SID override register is
    already written with correct value and skips re-writing it in that case.
    
    Fixes: 393d66fd2cac ("memory: tegra: Implement SID override programming")
    Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20221125040752.12627-1-amhetre@nvidia.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
module: Don't wait for GOING modules [+ + +]
Author: Petr Pavlu <petr.pavlu@suse.com>
Date:   Mon Dec 5 11:35:57 2022 +0100

    module: Don't wait for GOING modules
    
    commit 0254127ab977e70798707a7a2b757c9f3c971210 upstream.
    
    During a system boot, it can happen that the kernel receives a burst of
    requests to insert the same module but loading it eventually fails
    during its init call. For instance, udev can make a request to insert
    a frequency module for each individual CPU when another frequency module
    is already loaded which causes the init function of the new module to
    return an error.
    
    Since commit 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for
    modules that have finished loading"), the kernel waits for modules in
    MODULE_STATE_GOING state to finish unloading before making another
    attempt to load the same module.
    
    This creates unnecessary work in the described scenario and delays the
    boot. In the worst case, it can prevent udev from loading drivers for
    other devices and might cause timeouts of services waiting on them and
    subsequently a failed boot.
    
    This patch attempts a different solution for the problem 6e6de3dee51a
    was trying to solve. Rather than waiting for the unloading to complete,
    it returns a different error code (-EBUSY) for modules in the GOING
    state. This should avoid the error situation that was described in
    6e6de3dee51a (user space attempting to load a dependent module because
    the -EEXIST error code would suggest to user space that the first module
    had been loaded successfully), while avoiding the delay situation too.
    
    This has been tested on linux-next since December 2022 and passes
    all kmod selftests except test 0009 with module compression enabled
    but it has been confirmed that this issue has existed and has gone
    unnoticed since prior to this commit and can also be reproduced without
    module compression with a simple usleep(5000000) on tools/modprobe.c [0].
    These failures are caused by hitting the kernel mod_concurrent_max and can
    happen either due to a self inflicted kernel module auto-loead DoS somehow
    or on a system with large CPU count and each CPU count incorrectly triggering
    many module auto-loads. Both of those issues need to be fixed in-kernel.
    
    [0] https://lore.kernel.org/all/Y9A4fiobL6IHp%2F%2FP@bombadil.infradead.org/
    
    Fixes: 6e6de3dee51a ("kernel/module.c: Only return -EEXIST for modules that have finished loading")
    Co-developed-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    [mcgrof: enhance commit log with testing and kmod test result interpretation ]
    Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: E-switch, Fix setting of reserved fields on MODIFY_SCHEDULING_ELEMENT [+ + +]
Author: Maor Dickman <maord@nvidia.com>
Date:   Tue Dec 27 10:22:41 2022 +0200

    net/mlx5: E-switch, Fix setting of reserved fields on MODIFY_SCHEDULING_ELEMENT
    
    [ Upstream commit f51471d1935ce1f504fce6c115ce3bfbc32032b0 ]
    
    According to HW spec element_type, element_attributes and parent_element_id fields
    should be reserved (0x0) when calling MODIFY_SCHEDULING_ELEMENT command.
    
    This patch remove initialization of these fields when calling the command.
    
    Fixes: bd77bf1cb595 ("net/mlx5: Add SRIOV VF max rate configuration support")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Eli Cohen <elic@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: E-switch, Fix switchdev mode after devlink reload [+ + +]
Author: Chris Mi <cmi@nvidia.com>
Date:   Wed Dec 21 11:14:37 2022 +0200

    net/mlx5: E-switch, Fix switchdev mode after devlink reload
    
    [ Upstream commit 7c83d1f4c5adae9583e7fca1e3e830d6b061522d ]
    
    The cited commit removes eswitch mode none. So after devlink reload
    in switchdev mode, eswitch mode is not changed. But actually eswitch
    is disabled during devlink reload.
    
    Fix it by setting eswitch mode to legacy when disabling eswitch
    which is called by reload_down.
    
    Fixes: f019679ea5f2 ("net/mlx5: E-switch, Remove dependency between sriov and eswitch mode")
    Signed-off-by: Chris Mi <cmi@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/mlx5e: Avoid false lock dependency warning on tc_ht even more [+ + +]
Author: Vlad Buslov <vladbu@nvidia.com>
Date:   Thu Dec 15 16:44:33 2022 +0100

    net/mlx5e: Avoid false lock dependency warning on tc_ht even more
    
    [ Upstream commit 5aa56105930374928d567744595fd7ac525d0688 ]
    
    The cited commit changed class of tc_ht internal mutex in order to avoid
    false lock dependency with fs_core node and flow_table hash table
    structures. However, hash table implementation internally also includes a
    workqueue task with its own lockdep map which causes similar bogus lockdep
    splat[0]. Fix it by also adding dedicated class for hash table workqueue
    work structure of tc_ht.
    
    [0]:
    
    [ 1139.672465] ======================================================
    [ 1139.673552] WARNING: possible circular locking dependency detected
    [ 1139.674635] 6.1.0_for_upstream_debug_2022_12_12_17_02 #1 Not tainted
    [ 1139.675734] ------------------------------------------------------
    [ 1139.676801] modprobe/5998 is trying to acquire lock:
    [ 1139.677726] ffff88811e7b93b8 (&node->lock){++++}-{3:3}, at: down_write_ref_node+0x7c/0xe0 [mlx5_core]
    [ 1139.679662]
                   but task is already holding lock:
    [ 1139.680703] ffff88813c1f96a0 (&tc_ht_lock_key){+.+.}-{3:3}, at: rhashtable_free_and_destroy+0x38/0x6f0
    [ 1139.682223]
                   which lock already depends on the new lock.
    
    [ 1139.683640]
                   the existing dependency chain (in reverse order) is:
    [ 1139.684887]
                   -> #2 (&tc_ht_lock_key){+.+.}-{3:3}:
    [ 1139.685975]        __mutex_lock+0x12c/0x14b0
    [ 1139.686659]        rht_deferred_worker+0x35/0x1540
    [ 1139.687405]        process_one_work+0x7c2/0x1310
    [ 1139.688134]        worker_thread+0x59d/0xec0
    [ 1139.688820]        kthread+0x28f/0x330
    [ 1139.689444]        ret_from_fork+0x1f/0x30
    [ 1139.690106]
                   -> #1 ((work_completion)(&ht->run_work)){+.+.}-{0:0}:
    [ 1139.691250]        __flush_work+0xe8/0x900
    [ 1139.691915]        __cancel_work_timer+0x2ca/0x3f0
    [ 1139.692655]        rhashtable_free_and_destroy+0x22/0x6f0
    [ 1139.693472]        del_sw_flow_table+0x22/0xb0 [mlx5_core]
    [ 1139.694592]        tree_put_node+0x24c/0x450 [mlx5_core]
    [ 1139.695686]        tree_remove_node+0x6e/0x100 [mlx5_core]
    [ 1139.696803]        mlx5_destroy_flow_table+0x187/0x690 [mlx5_core]
    [ 1139.698017]        mlx5e_tc_nic_cleanup+0x2f8/0x400 [mlx5_core]
    [ 1139.699217]        mlx5e_cleanup_nic_rx+0x2b/0x210 [mlx5_core]
    [ 1139.700397]        mlx5e_detach_netdev+0x19d/0x2b0 [mlx5_core]
    [ 1139.701571]        mlx5e_suspend+0xdb/0x140 [mlx5_core]
    [ 1139.702665]        mlx5e_remove+0x89/0x190 [mlx5_core]
    [ 1139.703756]        auxiliary_bus_remove+0x52/0x70
    [ 1139.704492]        device_release_driver_internal+0x3c1/0x600
    [ 1139.705360]        bus_remove_device+0x2a5/0x560
    [ 1139.706080]        device_del+0x492/0xb80
    [ 1139.706724]        mlx5_rescan_drivers_locked+0x194/0x6a0 [mlx5_core]
    [ 1139.707961]        mlx5_unregister_device+0x7a/0xa0 [mlx5_core]
    [ 1139.709138]        mlx5_uninit_one+0x5f/0x160 [mlx5_core]
    [ 1139.710252]        remove_one+0xd1/0x160 [mlx5_core]
    [ 1139.711297]        pci_device_remove+0x96/0x1c0
    [ 1139.722721]        device_release_driver_internal+0x3c1/0x600
    [ 1139.723590]        unbind_store+0x1b1/0x200
    [ 1139.724259]        kernfs_fop_write_iter+0x348/0x520
    [ 1139.725019]        vfs_write+0x7b2/0xbf0
    [ 1139.725658]        ksys_write+0xf3/0x1d0
    [ 1139.726292]        do_syscall_64+0x3d/0x90
    [ 1139.726942]        entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 1139.727769]
                   -> #0 (&node->lock){++++}-{3:3}:
    [ 1139.728698]        __lock_acquire+0x2cf5/0x62f0
    [ 1139.729415]        lock_acquire+0x1c1/0x540
    [ 1139.730076]        down_write+0x8e/0x1f0
    [ 1139.730709]        down_write_ref_node+0x7c/0xe0 [mlx5_core]
    [ 1139.731841]        mlx5_del_flow_rules+0x6f/0x610 [mlx5_core]
    [ 1139.732982]        __mlx5_eswitch_del_rule+0xdd/0x560 [mlx5_core]
    [ 1139.734207]        mlx5_eswitch_del_offloaded_rule+0x14/0x20 [mlx5_core]
    [ 1139.735491]        mlx5e_tc_rule_unoffload+0x104/0x2b0 [mlx5_core]
    [ 1139.736716]        mlx5e_tc_unoffload_fdb_rules+0x10c/0x1f0 [mlx5_core]
    [ 1139.738007]        mlx5e_tc_del_fdb_flow+0xc3c/0xfa0 [mlx5_core]
    [ 1139.739213]        mlx5e_tc_del_flow+0x146/0xa20 [mlx5_core]
    [ 1139.740377]        _mlx5e_tc_del_flow+0x38/0x60 [mlx5_core]
    [ 1139.741534]        rhashtable_free_and_destroy+0x3be/0x6f0
    [ 1139.742351]        mlx5e_tc_ht_cleanup+0x1b/0x30 [mlx5_core]
    [ 1139.743512]        mlx5e_cleanup_rep_tx+0x4a/0xe0 [mlx5_core]
    [ 1139.744683]        mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
    [ 1139.745860]        mlx5e_netdev_change_profile+0xd9/0x1c0 [mlx5_core]
    [ 1139.747098]        mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
    [ 1139.748372]        mlx5e_vport_rep_unload+0x16a/0x1b0 [mlx5_core]
    [ 1139.749590]        __esw_offloads_unload_rep+0xb1/0xd0 [mlx5_core]
    [ 1139.750813]        mlx5_eswitch_unregister_vport_reps+0x409/0x5f0 [mlx5_core]
    [ 1139.752147]        mlx5e_rep_remove+0x62/0x80 [mlx5_core]
    [ 1139.753293]        auxiliary_bus_remove+0x52/0x70
    [ 1139.754028]        device_release_driver_internal+0x3c1/0x600
    [ 1139.754885]        driver_detach+0xc1/0x180
    [ 1139.755553]        bus_remove_driver+0xef/0x2e0
    [ 1139.756260]        auxiliary_driver_unregister+0x16/0x50
    [ 1139.757059]        mlx5e_rep_cleanup+0x19/0x30 [mlx5_core]
    [ 1139.758207]        mlx5e_cleanup+0x12/0x30 [mlx5_core]
    [ 1139.759295]        mlx5_cleanup+0xc/0x49 [mlx5_core]
    [ 1139.760384]        __x64_sys_delete_module+0x2b5/0x450
    [ 1139.761166]        do_syscall_64+0x3d/0x90
    [ 1139.761827]        entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 1139.762663]
                   other info that might help us debug this:
    
    [ 1139.763925] Chain exists of:
                     &node->lock --> (work_completion)(&ht->run_work) --> &tc_ht_lock_key
    
    [ 1139.765743]  Possible unsafe locking scenario:
    
    [ 1139.766688]        CPU0                    CPU1
    [ 1139.767399]        ----                    ----
    [ 1139.768111]   lock(&tc_ht_lock_key);
    [ 1139.768704]                                lock((work_completion)(&ht->run_work));
    [ 1139.769869]                                lock(&tc_ht_lock_key);
    [ 1139.770770]   lock(&node->lock);
    [ 1139.771326]
                    *** DEADLOCK ***
    
    [ 1139.772345] 2 locks held by modprobe/5998:
    [ 1139.772994]  #0: ffff88813c1ff0e8 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x8d/0x600
    [ 1139.774399]  #1: ffff88813c1f96a0 (&tc_ht_lock_key){+.+.}-{3:3}, at: rhashtable_free_and_destroy+0x38/0x6f0
    [ 1139.775822]
                   stack backtrace:
    [ 1139.776579] CPU: 3 PID: 5998 Comm: modprobe Not tainted 6.1.0_for_upstream_debug_2022_12_12_17_02 #1
    [ 1139.777935] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [ 1139.779529] Call Trace:
    [ 1139.779992]  <TASK>
    [ 1139.780409]  dump_stack_lvl+0x57/0x7d
    [ 1139.781015]  check_noncircular+0x278/0x300
    [ 1139.781687]  ? print_circular_bug+0x460/0x460
    [ 1139.782381]  ? rcu_read_lock_sched_held+0x3f/0x70
    [ 1139.783121]  ? lock_release+0x487/0x7c0
    [ 1139.783759]  ? orc_find.part.0+0x1f1/0x330
    [ 1139.784423]  ? mark_lock.part.0+0xef/0x2fc0
    [ 1139.785091]  __lock_acquire+0x2cf5/0x62f0
    [ 1139.785754]  ? register_lock_class+0x18e0/0x18e0
    [ 1139.786483]  lock_acquire+0x1c1/0x540
    [ 1139.787093]  ? down_write_ref_node+0x7c/0xe0 [mlx5_core]
    [ 1139.788195]  ? lockdep_hardirqs_on_prepare+0x3f0/0x3f0
    [ 1139.788978]  ? register_lock_class+0x18e0/0x18e0
    [ 1139.789715]  down_write+0x8e/0x1f0
    [ 1139.790292]  ? down_write_ref_node+0x7c/0xe0 [mlx5_core]
    [ 1139.791380]  ? down_write_killable+0x220/0x220
    [ 1139.792080]  ? find_held_lock+0x2d/0x110
    [ 1139.792713]  down_write_ref_node+0x7c/0xe0 [mlx5_core]
    [ 1139.793795]  mlx5_del_flow_rules+0x6f/0x610 [mlx5_core]
    [ 1139.794879]  __mlx5_eswitch_del_rule+0xdd/0x560 [mlx5_core]
    [ 1139.796032]  ? __esw_offloads_unload_rep+0xd0/0xd0 [mlx5_core]
    [ 1139.797227]  ? xa_load+0x11a/0x200
    [ 1139.797800]  ? __xa_clear_mark+0xf0/0xf0
    [ 1139.798438]  mlx5_eswitch_del_offloaded_rule+0x14/0x20 [mlx5_core]
    [ 1139.799660]  mlx5e_tc_rule_unoffload+0x104/0x2b0 [mlx5_core]
    [ 1139.800821]  mlx5e_tc_unoffload_fdb_rules+0x10c/0x1f0 [mlx5_core]
    [ 1139.802049]  ? mlx5_eswitch_get_uplink_priv+0x25/0x80 [mlx5_core]
    [ 1139.803260]  mlx5e_tc_del_fdb_flow+0xc3c/0xfa0 [mlx5_core]
    [ 1139.804398]  ? __cancel_work_timer+0x1c2/0x3f0
    [ 1139.805099]  ? mlx5e_tc_unoffload_from_slow_path+0x460/0x460 [mlx5_core]
    [ 1139.806387]  mlx5e_tc_del_flow+0x146/0xa20 [mlx5_core]
    [ 1139.807481]  _mlx5e_tc_del_flow+0x38/0x60 [mlx5_core]
    [ 1139.808564]  rhashtable_free_and_destroy+0x3be/0x6f0
    [ 1139.809336]  ? mlx5e_tc_del_flow+0xa20/0xa20 [mlx5_core]
    [ 1139.809336]  ? mlx5e_tc_del_flow+0xa20/0xa20 [mlx5_core]
    [ 1139.810455]  mlx5e_tc_ht_cleanup+0x1b/0x30 [mlx5_core]
    [ 1139.811552]  mlx5e_cleanup_rep_tx+0x4a/0xe0 [mlx5_core]
    [ 1139.812655]  mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
    [ 1139.813768]  mlx5e_netdev_change_profile+0xd9/0x1c0 [mlx5_core]
    [ 1139.814952]  mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
    [ 1139.816166]  mlx5e_vport_rep_unload+0x16a/0x1b0 [mlx5_core]
    [ 1139.817336]  __esw_offloads_unload_rep+0xb1/0xd0 [mlx5_core]
    [ 1139.818507]  mlx5_eswitch_unregister_vport_reps+0x409/0x5f0 [mlx5_core]
    [ 1139.819788]  ? mlx5_eswitch_uplink_get_proto_dev+0x30/0x30 [mlx5_core]
    [ 1139.821051]  ? kernfs_find_ns+0x137/0x310
    [ 1139.821705]  mlx5e_rep_remove+0x62/0x80 [mlx5_core]
    [ 1139.822778]  auxiliary_bus_remove+0x52/0x70
    [ 1139.823449]  device_release_driver_internal+0x3c1/0x600
    [ 1139.824240]  driver_detach+0xc1/0x180
    [ 1139.824842]  bus_remove_driver+0xef/0x2e0
    [ 1139.825504]  auxiliary_driver_unregister+0x16/0x50
    [ 1139.826245]  mlx5e_rep_cleanup+0x19/0x30 [mlx5_core]
    [ 1139.827322]  mlx5e_cleanup+0x12/0x30 [mlx5_core]
    [ 1139.828345]  mlx5_cleanup+0xc/0x49 [mlx5_core]
    [ 1139.829382]  __x64_sys_delete_module+0x2b5/0x450
    [ 1139.830119]  ? module_flags+0x300/0x300
    [ 1139.830750]  ? task_work_func_match+0x50/0x50
    [ 1139.831440]  ? task_work_cancel+0x20/0x20
    [ 1139.832088]  ? lockdep_hardirqs_on_prepare+0x273/0x3f0
    [ 1139.832873]  ? syscall_enter_from_user_mode+0x1d/0x50
    [ 1139.833661]  ? trace_hardirqs_on+0x2d/0x100
    [ 1139.834328]  do_syscall_64+0x3d/0x90
    [ 1139.834922]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
    [ 1139.835700] RIP: 0033:0x7f153e71288b
    [ 1139.836302] Code: 73 01 c3 48 8b 0d 9d 75 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6d 75 0e 00 f7 d8 64 89 01 48
    [ 1139.838866] RSP: 002b:00007ffe0a3ed938 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
    [ 1139.840020] RAX: ffffffffffffffda RBX: 0000564c2cbf8220 RCX: 00007f153e71288b
    [ 1139.841043] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000564c2cbf8288
    [ 1139.842072] RBP: 0000564c2cbf8220 R08: 0000000000000000 R09: 0000000000000000
    [ 1139.843094] R10: 00007f153e7a3ac0 R11: 0000000000000206 R12: 0000564c2cbf8288
    [ 1139.844118] R13: 0000000000000000 R14: 0000564c2cbf7ae8 R15: 00007ffe0a3efcb8
    
    Fixes: 9ba33339c043 ("net/mlx5e: Avoid false lock depenency warning on tc_ht")
    Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
    Reviewed-by: Eli Cohen <elic@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: QoS, Fix wrongfully setting parent_element_id on MODIFY_SCHEDULING_ELEMENT [+ + +]
Author: Maor Dickman <maord@nvidia.com>
Date:   Tue Dec 27 10:51:38 2022 +0200

    net/mlx5e: QoS, Fix wrongfully setting parent_element_id on MODIFY_SCHEDULING_ELEMENT
    
    [ Upstream commit 4ddf77f9bc76092d268bd3af447d60d9cc62b652 ]
    
    According to HW spec parent_element_id field should be reserved (0x0) when calling
    MODIFY_SCHEDULING_ELEMENT command.
    
    This patch remove the wrong initialization of reserved field, parent_element_id, on
    mlx5_qos_update_node.
    
    Fixes: 214baf22870c ("net/mlx5e: Support HTB offload")
    Signed-off-by: Maor Dickman <maord@nvidia.com>
    Reviewed-by: Eli Cohen <elic@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5e: Set decap action based on attr for sample [+ + +]
Author: Chris Mi <cmi@nvidia.com>
Date:   Thu Jan 12 04:30:27 2023 +0200

    net/mlx5e: Set decap action based on attr for sample
    
    [ Upstream commit ffa99b534732f90077f346c62094cab3d1ccddce ]
    
    Currently decap action is set based on tunnel_id. That means it is
    set unconditionally. But for decap, ct and sample actions, decap is
    done before ct. No need to decap again in sample.
    
    And the actions are set correctly when parsing. So set decap action
    based on attr instead of tunnel_id.
    
    Fixes: 2741f2230905 ("net/mlx5e: TC, Support sample offload action for tunneled traffic")
    Signed-off-by: Chris Mi <cmi@nvidia.com>
    Reviewed-by: Roi Dayan <roid@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: sch_taprio: do not schedule in taprio_reset() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Jan 23 08:45:52 2023 +0000

    net/sched: sch_taprio: do not schedule in taprio_reset()
    
    [ Upstream commit ea4fdbaa2f7798cb25adbe4fd52ffc6356f097bb ]
    
    As reported by syzbot and hinted by Vinicius, I should not have added
    a qdisc_synchronize() call in taprio_reset()
    
    taprio_reset() can be called with qdisc spinlock held (and BH disabled)
    as shown in included syzbot report [1].
    
    Only taprio_destroy() needed this synchronization, as explained
    in the blamed commit changelog.
    
    [1]
    
    BUG: scheduling while atomic: syz-executor150/5091/0x00000202
    2 locks held by syz-executor150/5091:
    Modules linked in:
    Preemption disabled at:
    [<0000000000000000>] 0x0
    Kernel panic - not syncing: scheduling while atomic: panic_on_warn set ...
    CPU: 1 PID: 5091 Comm: syz-executor150 Not tainted 6.2.0-rc3-syzkaller-00219-g010a74f52203 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
    Call Trace:
    <TASK>
    __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
    panic+0x2cc/0x626 kernel/panic.c:318
    check_panic_on_warn.cold+0x19/0x35 kernel/panic.c:238
    __schedule_bug.cold+0xd5/0xfe kernel/sched/core.c:5836
    schedule_debug kernel/sched/core.c:5865 [inline]
    __schedule+0x34e4/0x5450 kernel/sched/core.c:6500
    schedule+0xde/0x1b0 kernel/sched/core.c:6682
    schedule_timeout+0x14e/0x2a0 kernel/time/timer.c:2167
    schedule_timeout_uninterruptible kernel/time/timer.c:2201 [inline]
    msleep+0xb6/0x100 kernel/time/timer.c:2322
    qdisc_synchronize include/net/sch_generic.h:1295 [inline]
    taprio_reset+0x93/0x270 net/sched/sch_taprio.c:1703
    qdisc_reset+0x10c/0x770 net/sched/sch_generic.c:1022
    dev_reset_queue+0x92/0x130 net/sched/sch_generic.c:1285
    netdev_for_each_tx_queue include/linux/netdevice.h:2464 [inline]
    dev_deactivate_many+0x36d/0x9f0 net/sched/sch_generic.c:1351
    dev_deactivate+0xed/0x1b0 net/sched/sch_generic.c:1374
    qdisc_graft+0xe4a/0x1380 net/sched/sch_api.c:1080
    tc_modify_qdisc+0xb6b/0x19a0 net/sched/sch_api.c:1689
    rtnetlink_rcv_msg+0x43e/0xca0 net/core/rtnetlink.c:6141
    netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564
    netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
    netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356
    netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg+0xd3/0x120 net/socket.c:734
    ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476
    ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
    __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    
    Fixes: 3a415d59c1db ("net/sched: sch_taprio: fix possible use-after-free")
    Link: https://lore.kernel.org/netdev/167387581653.2747.13878941339893288655.git-patchwork-notify@kernel.org/T/
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Link: https://lore.kernel.org/r/20230123084552.574396-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/sched: sch_taprio: fix possible use-after-free [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 13 16:48:49 2023 +0000

    net/sched: sch_taprio: fix possible use-after-free
    
    [ Upstream commit 3a415d59c1dbec9d772dbfab2d2520d98360caae ]
    
    syzbot reported a nasty crash [1] in net_tx_action() which
    made little sense until we got a repro.
    
    This repro installs a taprio qdisc, but providing an
    invalid TCA_RATE attribute.
    
    qdisc_create() has to destroy the just initialized
    taprio qdisc, and taprio_destroy() is called.
    
    However, the hrtimer used by taprio had already fired,
    therefore advance_sched() called __netif_schedule().
    
    Then net_tx_action was trying to use a destroyed qdisc.
    
    We can not undo the __netif_schedule(), so we must wait
    until one cpu serviced the qdisc before we can proceed.
    
    Many thanks to Alexander Potapenko for his help.
    
    [1]
    BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
    BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
    BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
    BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
     queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]
     do_raw_spin_trylock include/linux/spinlock.h:191 [inline]
     __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]
     _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138
     spin_trylock include/linux/spinlock.h:359 [inline]
     qdisc_run_begin include/net/sch_generic.h:187 [inline]
     qdisc_run+0xee/0x540 include/net/pkt_sched.h:125
     net_tx_action+0x77c/0x9a0 net/core/dev.c:5086
     __do_softirq+0x1cc/0x7fb kernel/softirq.c:571
     run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934
     smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164
     kthread+0x31b/0x430 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30
    
    Uninit was created at:
     slab_post_alloc_hook mm/slab.h:732 [inline]
     slab_alloc_node mm/slub.c:3258 [inline]
     __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970
     kmalloc_reserve net/core/skbuff.c:358 [inline]
     __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430
     alloc_skb include/linux/skbuff.h:1257 [inline]
     nlmsg_new include/net/netlink.h:953 [inline]
     netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436
     netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507
     rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482
     ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536
     __sys_sendmsg net/socket.c:2565 [inline]
     __do_sys_sendmsg net/socket.c:2574 [inline]
     __se_sys_sendmsg net/socket.c:2572 [inline]
     __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
    
    Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/tg3: resolve deadlock in tg3_reset_task() during EEH [+ + +]
Author: David Christensen <drc@linux.vnet.ibm.com>
Date:   Tue Jan 24 13:53:39 2023 -0500

    net/tg3: resolve deadlock in tg3_reset_task() during EEH
    
    [ Upstream commit 6c4ca03bd890566d873e3593b32d034bf2f5a087 ]
    
    During EEH error injection testing, a deadlock was encountered in the tg3
    driver when tg3_io_error_detected() was attempting to cancel outstanding
    reset tasks:
    
    crash> foreach UN bt
    ...
    PID: 159    TASK: c0000000067c6000  CPU: 8   COMMAND: "eehd"
    ...
     #5 [c00000000681f990] __cancel_work_timer at c00000000019fd18
     #6 [c00000000681fa30] tg3_io_error_detected at c00800000295f098 [tg3]
     #7 [c00000000681faf0] eeh_report_error at c00000000004e25c
    ...
    
    PID: 290    TASK: c000000036e5f800  CPU: 6   COMMAND: "kworker/6:1"
    ...
     #4 [c00000003721fbc0] rtnl_lock at c000000000c940d8
     #5 [c00000003721fbe0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c00000003721fc60] process_one_work at c00000000019e5c4
    ...
    
    PID: 296    TASK: c000000037a65800  CPU: 21  COMMAND: "kworker/21:1"
    ...
     #4 [c000000037247bc0] rtnl_lock at c000000000c940d8
     #5 [c000000037247be0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c000000037247c60] process_one_work at c00000000019e5c4
    ...
    
    PID: 655    TASK: c000000036f49000  CPU: 16  COMMAND: "kworker/16:2"
    ...:1
    
     #4 [c0000000373ebbc0] rtnl_lock at c000000000c940d8
     #5 [c0000000373ebbe0] tg3_reset_task at c008000002969358 [tg3]
     #6 [c0000000373ebc60] process_one_work at c00000000019e5c4
    ...
    
    Code inspection shows that both tg3_io_error_detected() and
    tg3_reset_task() attempt to acquire the RTNL lock at the beginning of
    their code blocks.  If tg3_reset_task() should happen to execute between
    the times when tg3_io_error_deteced() acquires the RTNL lock and
    tg3_reset_task_cancel() is called, a deadlock will occur.
    
    Moving tg3_reset_task_cancel() call earlier within the code block, prior
    to acquiring RTNL, prevents this from happening, but also exposes another
    deadlock issue where tg3_reset_task() may execute AFTER
    tg3_io_error_detected() has executed:
    
    crash> foreach UN bt
    PID: 159    TASK: c0000000067d2000  CPU: 9   COMMAND: "eehd"
    ...
     #4 [c000000006867a60] rtnl_lock at c000000000c940d8
     #5 [c000000006867a80] tg3_io_slot_reset at c0080000026c2ea8 [tg3]
     #6 [c000000006867b00] eeh_report_reset at c00000000004de88
    ...
    PID: 363    TASK: c000000037564000  CPU: 6   COMMAND: "kworker/6:1"
    ...
     #3 [c000000036c1bb70] msleep at c000000000259e6c
     #4 [c000000036c1bba0] napi_disable at c000000000c6b848
     #5 [c000000036c1bbe0] tg3_reset_task at c0080000026d942c [tg3]
     #6 [c000000036c1bc60] process_one_work at c00000000019e5c4
    ...
    
    This issue can be avoided by aborting tg3_reset_task() if EEH error
    recovery is already in progress.
    
    Fixes: db84bf43ef23 ("tg3: tg3_reset_task() needs to use rtnl_lock to synchronize")
    Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Link: https://lore.kernel.org/r/20230124185339.225806-1-drc@linux.vnet.ibm.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: dsa: microchip: fix probe of I2C-connected KSZ8563 [+ + +]
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Fri Jan 20 12:09:32 2023 +0100

    net: dsa: microchip: fix probe of I2C-connected KSZ8563
    
    [ Upstream commit 360fdc999d92db4a4adbba0db8641396dc9f1b13 ]
    
    Starting with commit eee16b147121 ("net: dsa: microchip: perform the
    compatibility check for dev probed"), the KSZ switch driver now bails
    out if it thinks the DT compatible doesn't match the actual chip ID
    read back from the hardware:
    
      ksz9477-switch 1-005f: Device tree specifies chip KSZ9893 but found
      KSZ8563, please fix it!
    
    For the KSZ8563, which used ksz_switch_chips[KSZ9893], this was fine
    at first, because it indeed shares the same chip id as the KSZ9893.
    
    Commit b44908095612 ("net: dsa: microchip: add separate struct
    ksz_chip_data for KSZ8563 chip") started differentiating KSZ9893
    compatible chips by consulting the 0x1F register. The resulting breakage
    was fixed for the SPI driver in the same commit by introducing the
    appropriate ksz_switch_chips[KSZ8563], but not for the I2C driver.
    
    Fix this for I2C-connected KSZ8563 now to get it probing again.
    
    Fixes: b44908095612 ("net: dsa: microchip: add separate struct ksz_chip_data for KSZ8563 chip").
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
    Acked-by: Arun Ramadoss <arun.ramadoss@microchip.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20230120110933.1151054-1-a.fatoum@pengutronix.de
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: microchip: ksz9477: port map correction in ALU table entry register [+ + +]
Author: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com>
Date:   Wed Jan 18 23:17:35 2023 +0530

    net: dsa: microchip: ksz9477: port map correction in ALU table entry register
    
    [ Upstream commit 6c977c5c2e4c5d8ad1b604724cc344e38f96fe9b ]
    
    ALU table entry 2 register in KSZ9477 have bit positions reserved for
    forwarding port map. This field is referred in ksz9477_fdb_del() for
    clearing forward port map and alu table.
    
    But current fdb_del refer ALU table entry 3 register for accessing forward
    port map. Update ksz9477_fdb_del() to get forward port map from correct
    alu table entry register.
    
    With this bug, issue can be observed while deleting static MAC entries.
    Delete any specific MAC entry using "bridge fdb del" command. This should
    clear all the specified MAC entries. But it is observed that entries with
    self static alone are retained.
    
    Tested on LAN9370 EVB since ksz9477_fdb_del() is used common across
    LAN937x and KSZ series.
    
    Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
    Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Link: https://lore.kernel.org/r/20230118174735.702377-1-rakesh.sankaranarayanan@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Thu Jan 12 12:54:40 2023 +0200

    net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()
    
    [ Upstream commit 3c463721a73bdb57a913e0d3124677a3758886fc ]
    
    This lockdep splat says it better than I could:
    
    ================================
    WARNING: inconsistent lock state
    6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted
    --------------------------------
    inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
    kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:
    ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0
    {IN-SOFTIRQ-W} state was registered at:
      _raw_spin_lock+0x5c/0xc0
      sch_direct_xmit+0x148/0x37c
      __dev_queue_xmit+0x528/0x111c
      ip6_finish_output2+0x5ec/0xb7c
      ip6_finish_output+0x240/0x3f0
      ip6_output+0x78/0x360
      ndisc_send_skb+0x33c/0x85c
      ndisc_send_rs+0x54/0x12c
      addrconf_rs_timer+0x154/0x260
      call_timer_fn+0xb8/0x3a0
      __run_timers.part.0+0x214/0x26c
      run_timer_softirq+0x3c/0x74
      __do_softirq+0x14c/0x5d8
      ____do_softirq+0x10/0x20
      call_on_irq_stack+0x2c/0x5c
      do_softirq_own_stack+0x1c/0x30
      __irq_exit_rcu+0x168/0x1a0
      irq_exit_rcu+0x10/0x40
      el1_interrupt+0x38/0x64
    irq event stamp: 7825
    hardirqs last  enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130
    hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8
    softirqs last  enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8
    softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(_xmit_ETHER#2);
      <Interrupt>
        lock(_xmit_ETHER#2);
    
     *** DEADLOCK ***
    
    3 locks held by kworker/1:3/179:
     #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
     #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0
     #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34
    
    Workqueue: events enetc_tx_onestep_tstamp
    Call trace:
     print_usage_bug.part.0+0x208/0x22c
     mark_lock+0x7f0/0x8b0
     __lock_acquire+0x7c4/0x1ce0
     lock_acquire.part.0+0xe0/0x220
     lock_acquire+0x68/0x84
     _raw_spin_lock+0x5c/0xc0
     netif_freeze_queues+0x5c/0xc0
     netif_tx_lock+0x24/0x34
     enetc_tx_onestep_tstamp+0x20/0x100
     process_one_work+0x28c/0x6c0
     worker_thread+0x74/0x450
     kthread+0x118/0x11c
    
    but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in
    process context, therefore with softirqs enabled (i.o.w., it can be
    interrupted by a softirq). If we hold the netif_tx_lock() when there is
    an interrupt, and the NET_TX softirq then gets scheduled, this will take
    the netif_tx_lock() a second time and deadlock the kernel.
    
    To solve this, use netif_tx_lock_bh(), which blocks softirqs from
    running.
    
    Fixes: 7294380c5211 ("enetc: support PTP Sync packet one-step timestamping")
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20230112105440.1786799-1-vladimir.oltean@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: adi: adin1110: Fix multicast offloading [+ + +]
Author: Alexandru Tachici <alexandru.tachici@analog.com>
Date:   Fri Jan 20 11:08:46 2023 +0200

    net: ethernet: adi: adin1110: Fix multicast offloading
    
    [ Upstream commit 8a4f6d023221c4b052ddfa1db48b27871bad6e96 ]
    
    Driver marked broadcast/multicast frames as offloaded incorrectly.
    Mark them as offloaded only when HW offloading has been enabled.
    This should happen only for ADIN2111 when both ports are bridged
    by the software.
    
    Fixes: bc93e19d088b ("net: ethernet: adi: Add ADIN1110 support")
    Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20230120090846.18172-1-alexandru.tachici@analog.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fec: Use page_pool_put_full_page when freeing rx buffers [+ + +]
Author: Wei Fang <wei.fang@nxp.com>
Date:   Thu Jan 19 12:37:47 2023 +0800

    net: fec: Use page_pool_put_full_page when freeing rx buffers
    
    [ Upstream commit e38553bdc377e3e7a6caa9dd9770d8b644d8dac3 ]
    
    The page_pool_release_page was used when freeing rx buffers, and this
    function just unmaps the page (if mapped) and does not recycle the page.
    So after hundreds of down/up the eth0, the system will out of memory.
    For more details, please refer to the following reproduce steps and
    bug logs. To solve this issue and refer to the doc of page pool, the
    page_pool_put_full_page should be used to replace page_pool_release_page.
    Because this API will try to recycle the page if the page refcnt equal to
    1. After testing 20000 times, the issue can not be reproduced anymore
    (about testing 391 times the issue will occur on i.MX8MN-EVK before).
    
    Reproduce steps:
    Create the test script and run the script. The script content is as
    follows:
    LOOPS=20000
    i=1
    while [ $i -le $LOOPS ]
    do
        echo "TINFO:ENET $curface up and down test $i times"
        org_macaddr=$(cat /sys/class/net/eth0/address)
        ifconfig eth0 down
        ifconfig eth0  hw ether $org_macaddr up
        i=$(expr $i + 1)
    done
    sleep 5
    if cat /sys/class/net/eth0/operstate | grep 'up';then
        echo "TEST PASS"
    else
        echo "TEST FAIL"
    fi
    
    Bug detail logs:
    TINFO:ENET  up and down test 391 times
    [  850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)
    [  853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [  853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
    [  870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec
    [  931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec
    TINFO:ENET  up and down test 392 times
    [  991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec
    [ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec
    [ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)
    [ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec
    [ 1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
    [ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec
    [ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec
    [ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec
    [ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec
    TINFO:ENET  up and down test 393 times
    [ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec
    [ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec
    [ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec
    [ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec
    [ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec
    [ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)
    [ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
    [ 1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    [ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec
    [ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec
    [ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec
    [ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec
    [ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec
    [ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec
    TINFO:ENET  up and down test 394 times
    [ 1492.830522] page_pool_release_retry() stalled pool shutdown 310 inflight 181 sec
    [ 1519.358519] page_pool_release_retry() stalled pool shutdown 308 inflight 483 sec
    [ 1535.166545] page_pool_release_retry() stalled pool shutdown 2 inflight 724 sec
    [ 1537.090278] eth_test2.sh invoked oom-killer: gfp_mask=0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), order=0, oom_score_adj=0
    [ 1537.101192] CPU: 3 PID: 2379 Comm: eth_test2.sh Tainted: G         C         6.1.1+g56321e101aca #1
    [ 1537.110249] Hardware name: NXP i.MX8MNano EVK board (DT)
    [ 1537.115561] Call trace:
    [ 1537.118005]  dump_backtrace.part.0+0xe0/0xf0
    [ 1537.122289]  show_stack+0x18/0x40
    [ 1537.125608]  dump_stack_lvl+0x64/0x80
    [ 1537.129276]  dump_stack+0x18/0x34
    [ 1537.132592]  dump_header+0x44/0x208
    [ 1537.136083]  oom_kill_process+0x2b4/0x2c0
    [ 1537.140097]  out_of_memory+0xe4/0x594
    [ 1537.143766]  __alloc_pages+0xb68/0xd00
    [ 1537.147521]  alloc_pages+0xac/0x160
    [ 1537.151013]  __get_free_pages+0x14/0x40
    [ 1537.154851]  pgd_alloc+0x1c/0x30
    [ 1537.158082]  mm_init+0xf8/0x1d0
    [ 1537.161228]  mm_alloc+0x48/0x60
    [ 1537.164368]  alloc_bprm+0x7c/0x240
    [ 1537.167777]  do_execveat_common.isra.0+0x70/0x240
    [ 1537.172486]  __arm64_sys_execve+0x40/0x54
    [ 1537.176502]  invoke_syscall+0x48/0x114
    [ 1537.180255]  el0_svc_common.constprop.0+0xcc/0xec
    [ 1537.184964]  do_el0_svc+0x2c/0xd0
    [ 1537.188280]  el0_svc+0x2c/0x84
    [ 1537.191340]  el0t_64_sync_handler+0xf4/0x120
    [ 1537.195613]  el0t_64_sync+0x18c/0x190
    [ 1537.199334] Mem-Info:
    [ 1537.201620] active_anon:342 inactive_anon:10343 isolated_anon:0
    [ 1537.201620]  active_file:54 inactive_file:112 isolated_file:0
    [ 1537.201620]  unevictable:0 dirty:0 writeback:0
    [ 1537.201620]  slab_reclaimable:2620 slab_unreclaimable:7076
    [ 1537.201620]  mapped:1489 shmem:2473 pagetables:466
    [ 1537.201620]  sec_pagetables:0 bounce:0
    [ 1537.201620]  kernel_misc_reclaimable:0
    [ 1537.201620]  free:136672 free_pcp:96 free_cma:129241
    [ 1537.240419] Node 0 active_anon:1368kB inactive_anon:41372kB active_file:216kB inactive_file:5052kB unevictable:0kB isolated(anon):0kB isolated(file):0kB s
    [ 1537.271422] Node 0 DMA free:541636kB boost:0kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB active_anon:1368kB inactive_anon:41372kB actiB
    [ 1537.300219] lowmem_reserve[]: 0 0 0 0
    [ 1537.303929] Node 0 DMA: 1015*4kB (UMEC) 743*8kB (UMEC) 417*16kB (UMEC) 235*32kB (UMEC) 116*64kB (UMEC) 25*128kB (UMEC) 4*256kB (UC) 2*512kB (UC) 0*1024kBB
    [ 1537.323938] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
    [ 1537.332708] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB
    [ 1537.341292] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
    [ 1537.349776] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB
    [ 1537.358087] 2939 total pagecache pages
    [ 1537.361876] 0 pages in swap cache
    [ 1537.365229] Free swap  = 0kB
    [ 1537.368147] Total swap = 0kB
    [ 1537.371065] 516096 pages RAM
    [ 1537.373959] 0 pages HighMem/MovableOnly
    [ 1537.377834] 17302 pages reserved
    [ 1537.381103] 163840 pages cma reserved
    [ 1537.384809] 0 pages hwpoisoned
    [ 1537.387902] Tasks state (memory values in pages):
    [ 1537.392652] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
    [ 1537.401356] [    201]   993   201     1130       72    45056        0             0 rpcbind
    [ 1537.409772] [    202]     0   202     4529     1640    77824        0          -250 systemd-journal
    [ 1537.418861] [    222]     0   222     4691      801    69632        0         -1000 systemd-udevd
    [ 1537.427787] [    248]   994   248    20914      130    65536        0             0 systemd-timesyn
    [ 1537.436884] [    497]     0   497      620       31    49152        0             0 atd
    [ 1537.444938] [    500]     0   500      854       77    53248        0             0 crond
    [ 1537.453165] [    503]   997   503     1470      160    49152        0          -900 dbus-daemon
    [ 1537.461908] [    505]     0   505      633       24    40960        0             0 firmwared
    [ 1537.470491] [    513]     0   513     2507      180    61440        0             0 ofonod
    [ 1537.478800] [    514]   990   514    69640      137    81920        0             0 parsec
    [ 1537.487120] [    533]     0   533      599       39    40960        0             0 syslogd
    [ 1537.495518] [    534]     0   534     4546      148    65536        0             0 systemd-logind
    [ 1537.504560] [    535]     0   535      690       24    45056        0             0 tee-supplicant
    [ 1537.513564] [    540]   996   540     2769      168    61440        0             0 systemd-network
    [ 1537.522680] [    566]     0   566     3878      228    77824        0             0 connmand
    [ 1537.531168] [    645]   998   645     1538      133    57344        0             0 avahi-daemon
    [ 1537.540004] [    646]   998   646     1461       64    57344        0             0 avahi-daemon
    [ 1537.548846] [    648]   992   648      781       41    45056        0             0 rpc.statd
    [ 1537.557415] [    650] 64371   650      590       23    45056        0             0 ninfod
    [ 1537.565754] [    653] 61563   653      555       24    45056        0             0 rdisc
    [ 1537.573971] [    655]     0   655   374569     2999   290816        0          -999 containerd
    [ 1537.582621] [    658]     0   658     1311       20    49152        0             0 agetty
    [ 1537.590922] [    663]     0   663     1529       97    49152        0             0 login
    [ 1537.599138] [    666]     0   666     3430      202    69632        0             0 wpa_supplicant
    [ 1537.608147] [    667]     0   667     2344       96    61440        0             0 systemd-userdbd
    [ 1537.617240] [    677]     0   677     2964      314    65536        0           100 systemd
    [ 1537.625651] [    679]     0   679     3720      646    73728        0           100 (sd-pam)
    [ 1537.634138] [    687]     0   687     1289      403    45056        0             0 sh
    [ 1537.642108] [    789]     0   789      970       93    45056        0             0 eth_test2.sh
    [ 1537.650955] [   2355]     0  2355     2346       94    61440        0             0 systemd-userwor
    [ 1537.660046] [   2356]     0  2356     2346       94    61440        0             0 systemd-userwor
    [ 1537.669137] [   2358]     0  2358     2346       95    57344        0             0 systemd-userwor
    [ 1537.678258] [   2379]     0  2379      970       93    45056        0             0 eth_test2.sh
    [ 1537.687098] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/user@0.service,tas0
    [ 1537.703009] Out of memory: Killed process 679 ((sd-pam)) total-vm:14880kB, anon-rss:2584kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:72kB oom_score_ad0
    [ 1553.246526] page_pool_release_retry() stalled pool shutdown 310 inflight 241 sec
    
    Fixes: 95698ff6177b ("net: fec: using page pool to manage RX buffers")
    Signed-off-by: Wei Fang <wei.fang@nxp.com>
    Reviewed-by: shenwei wang <Shenwei.wang@nxp.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: fix UaF in netns ops registration error path [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Jan 19 19:55:45 2023 +0100

    net: fix UaF in netns ops registration error path
    
    [ Upstream commit 71ab9c3e2253619136c31c89dbb2c69305cc89b1 ]
    
    If net_assign_generic() fails, the current error path in ops_init() tries
    to clear the gen pointer slot. Anyway, in such error path, the gen pointer
    itself has not been modified yet, and the existing and accessed one is
    smaller than the accessed index, causing an out-of-bounds error:
    
     BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
     Write of size 8 at addr ffff888109124978 by task modprobe/1018
    
     CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
     Call Trace:
      <TASK>
      dump_stack_lvl+0x6a/0x9f
      print_address_description.constprop.0+0x86/0x2b5
      print_report+0x11b/0x1fb
      kasan_report+0x87/0xc0
      ops_init+0x2de/0x320
      register_pernet_operations+0x2e4/0x750
      register_pernet_subsys+0x24/0x40
      tcf_register_action+0x9f/0x560
      do_one_initcall+0xf9/0x570
      do_init_module+0x190/0x650
      load_module+0x1fa5/0x23c0
      __do_sys_finit_module+0x10d/0x1b0
      do_syscall_64+0x58/0x80
      entry_SYSCALL_64_after_hwframe+0x72/0xdc
     RIP: 0033:0x7f42518f778d
     Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d cb 56 2c 00 f7 d8 64 89 01 48
     RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
     RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d
     RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003
     RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
     R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000
      </TASK>
    
    This change addresses the issue by skipping the gen pointer
    de-reference in the mentioned error-path.
    
    Found by code inspection and verified with explicit error injection
    on a kasan-enabled kernel.
    
    Fixes: d266935ac43d ("net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Link: https://lore.kernel.org/r/cec4e0f3bb2c77ac03a6154a8508d3930beb5f0f.1674154348.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ipa: disable ipa interrupt during suspend [+ + +]
Author: Caleb Connolly <caleb.connolly@linaro.org>
Date:   Sun Jan 15 17:59:24 2023 +0000

    net: ipa: disable ipa interrupt during suspend
    
    [ Upstream commit 9ec9b2a30853ba843b70ea16f196e5fe3327be5f ]
    
    The IPA interrupt can fire when pm_runtime is disabled due to it racing
    with the PM suspend/resume code. This causes a splat in the interrupt
    handler when it tries to call pm_runtime_get().
    
    Explicitly disable the interrupt in our ->suspend callback, and
    re-enable it in ->resume to avoid this. If there is an interrupt pending
    it will be handled after resuming. The interrupt is a wake_irq, as a
    result even when disabled if it fires it will cause the system to wake
    from suspend as well as cancel any suspend transition that may be in
    progress. If there is an interrupt pending, the ipa_isr_thread handler
    will be called after resuming.
    
    Fixes: 1aac309d3207 ("net: ipa: use autosuspend")
    Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
    Reviewed-by: Alex Elder <elder@linaro.org>
    Link: https://lore.kernel.org/r/20230115175925.465918-1-caleb.connolly@linaro.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan966x: add missing fwnode_handle_put() for ports node [+ + +]
Author: Clément Léger <clement.leger@bootlin.com>
Date:   Thu Jan 12 17:13:11 2023 +0100

    net: lan966x: add missing fwnode_handle_put() for ports node
    
    [ Upstream commit 925f3deb45df73173a33e1e81db77575f4ffde39 ]
    
    Since the "ethernet-ports" node is retrieved using
    device_get_named_child_node(), it should be release after using it. Add
    missing fwnode_handle_put() and move the code that retrieved the node
    from device-tree to avoid complicated handling in case of error.
    
    Fixes: db8bcaad5393 ("net: lan966x: add the basic lan966x driver")
    Signed-off-by: Clément Léger <clement.leger@bootlin.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20230112161311.495124-1-clement.leger@bootlin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: macb: fix PTP TX timestamp failure due to packet padding [+ + +]
Author: Robert Hancock <robert.hancock@calian.com>
Date:   Mon Jan 16 15:41:33 2023 -0600

    net: macb: fix PTP TX timestamp failure due to packet padding
    
    [ Upstream commit 7b90f5a665acd46efbbfa677a3a3a18d01ad6487 ]
    
    PTP TX timestamp handling was observed to be broken with this driver
    when using the raw Layer 2 PTP encapsulation. ptp4l was not receiving
    the expected TX timestamp after transmitting a packet, causing it to
    enter a failure state.
    
    The problem appears to be due to the way that the driver pads packets
    which are smaller than the Ethernet minimum of 60 bytes. If headroom
    space was available in the SKB, this caused the driver to move the data
    back to utilize it. However, this appears to cause other data references
    in the SKB to become inconsistent. In particular, this caused the
    ptp_one_step_sync function to later (in the TX completion path) falsely
    detect the packet as a one-step SYNC packet, even when it was not, which
    caused the TX timestamp to not be processed when it should be.
    
    Using the headroom for this purpose seems like an unnecessary complexity
    as this is not a hot path in the driver, and in most cases it appears
    that there is sufficient tailroom to not require using the headroom
    anyway. Remove this usage of headroom to prevent this inconsistency from
    occurring and causing other problems.
    
    Fixes: 653e92a9175e ("net: macb: add support for padding and fcs computation")
    Signed-off-by: Robert Hancock <robert.hancock@calian.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> # on SAMA7G5
    Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mana: Fix IRQ name - add PCI and queue number [+ + +]
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Thu Jan 19 12:59:10 2023 -0800

    net: mana: Fix IRQ name - add PCI and queue number
    
    [ Upstream commit 20e3028c39a5bf882e91e717da96d14f1acec40e ]
    
    The PCI and queue number info is missing in IRQ names.
    
    Add PCI and queue number to IRQ names, to allow CPU affinity
    tuning scripts to work.
    
    Cc: stable@vger.kernel.org
    Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Link: https://lore.kernel.org/r/1674161950-19708-1-git-send-email-haiyangz@microsoft.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mctp: add an explicit reference from a mctp_sk_key to sock [+ + +]
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Tue Jan 24 10:01:03 2023 +0800

    net: mctp: add an explicit reference from a mctp_sk_key to sock
    
    [ Upstream commit de8a6b15d9654c3e4f672d76da9d9df8ee06331d ]
    
    Currently, we correlate the mctp_sk_key lifetime to the sock lifetime
    through the sock hash/unhash operations, but this is pretty tenuous, and
    there are cases where we may have a temporary reference to an unhashed
    sk.
    
    This change makes the reference more explicit, by adding a hold on the
    sock when it's associated with a mctp_sk_key, released on final key
    unref.
    
    Fixes: 73c618456dc5 ("mctp: locking, lifetime and validity changes for sk_keys")
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mctp: hold key reference when looking up a general key [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jan 24 10:01:05 2023 +0800

    net: mctp: hold key reference when looking up a general key
    
    [ Upstream commit 6e54ea37e344f145665c2dc3cc534b92529e8de5 ]
    
    Currently, we have a race where we look up a sock through a "general"
    (ie, not directly associated with the (src,dest,tag) tuple) key, then
    drop the key reference while still holding the key's sock.
    
    This change expands the key reference until we've finished using the
    sock, and hence the sock reference too.
    
    Commit message changes from Jeremy Kerr <jk@codeconstruct.com.au>.
    
    Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
    Fixes: 73c618456dc5 ("mctp: locking, lifetime and validity changes for sk_keys")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mctp: mark socks as dead on unhash, prevent re-add [+ + +]
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Tue Jan 24 10:01:06 2023 +0800

    net: mctp: mark socks as dead on unhash, prevent re-add
    
    [ Upstream commit b98e1a04e27fddfdc808bf46fe78eca30db89ab3 ]
    
    Once a socket has been unhashed, we want to prevent it from being
    re-used in a sk_key entry as part of a routing operation.
    
    This change marks the sk as SOCK_DEAD on unhash, which prevents addition
    into the net's key list.
    
    We need to do this during the key add path, rather than key lookup, as
    we release the net keys_lock between those operations.
    
    Fixes: 4a992bbd3650 ("mctp: Implement message fragmentation & reassembly")
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mctp: move expiry timer delete to unhash [+ + +]
Author: Jeremy Kerr <jk@codeconstruct.com.au>
Date:   Tue Jan 24 10:01:04 2023 +0800

    net: mctp: move expiry timer delete to unhash
    
    [ Upstream commit 5f41ae6fca9d40ab3cb9b0507931ef7a9b3ea50b ]
    
    Currently, we delete the key expiry timer (in sk->close) before
    unhashing the sk. This means that another thread may find the sk through
    its presence on the key list, and re-queue the timer.
    
    This change moves the timer deletion to the unhash, after we have made
    the key no longer observable, so the timer cannot be re-queued.
    
    Fixes: 7b14e15ae6f4 ("mctp: Implement a timeout for tags")
    Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mdio-mux-meson-g12a: force internal PHY off on mux switch [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Tue Jan 24 11:11:57 2023 +0100

    net: mdio-mux-meson-g12a: force internal PHY off on mux switch
    
    [ Upstream commit 7083df59abbc2b7500db312cac706493be0273ff ]
    
    Force the internal PHY off then on when switching to the internal path.
    This fixes problems where the PHY ID is not properly set.
    
    Fixes: 7090425104db ("net: phy: add amlogic g12a mdio mux support")
    Suggested-by: Qi Duan <qi.duan@amlogic.com>
    Co-developed-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Link: https://lore.kernel.org/r/20230124101157.232234-1-jbrunet@baylibre.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mdio: validate parameter addr in mdiobus_get_phy() [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 15 11:54:06 2023 +0100

    net: mdio: validate parameter addr in mdiobus_get_phy()
    
    [ Upstream commit 867dbe784c5010a466f00a7d1467c1c5ea569c75 ]
    
    The caller may pass any value as addr, what may result in an out-of-bounds
    access to array mdio_map. One existing case is stmmac_init_phy() that
    may pass -1 as addr. Therefore validate addr before using it.
    
    Fixes: 7f854420fbfe ("phy: Add API for {un}registering an mdio device to a bus.")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/cdf664ea-3312-e915-73f8-021678d08887@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mlx5: eliminate anonymous module_init & module_exit [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Tue Aug 30 20:12:29 2022 -0700

    net: mlx5: eliminate anonymous module_init & module_exit
    
    [ Upstream commit 2c1e1b949024989e20907b84e11a731a50778416 ]
    
    Eliminate anonymous module_init() and module_exit(), which can lead to
    confusion or ambiguity when reading System.map, crashes/oops/bugs,
    or an initcall_debug log.
    
    Give each of these init and exit functions unique driver-specific
    names to eliminate the anonymous names.
    
    Example 1: (System.map)
     ffffffff832fc78c t init
     ffffffff832fc79e t init
     ffffffff832fc8f8 t init
    
    Example 2: (initcall_debug log)
     calling  init+0x0/0x12 @ 1
     initcall init+0x0/0x12 returned 0 after 15 usecs
     calling  init+0x0/0x60 @ 1
     initcall init+0x0/0x60 returned 0 after 2 usecs
     calling  init+0x0/0x9a @ 1
     initcall init+0x0/0x9a returned 0 after 74 usecs
    
    Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Eli Cohen <eli@mellanox.com>
    Cc: Saeed Mahameed <saeedm@nvidia.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: linux-rdma@vger.kernel.org
    Reviewed-by: Ira Weiny <ira.weiny@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: nfc: Fix use-after-free in local_cleanup() [+ + +]
Author: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Date:   Wed Jan 11 22:19:14 2023 +0900

    net: nfc: Fix use-after-free in local_cleanup()
    
    [ Upstream commit 4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6 ]
    
    Fix a use-after-free that occurs in kfree_skb() called from
    local_cleanup(). This could happen when killing nfc daemon (e.g. neard)
    after detaching an nfc device.
    When detaching an nfc device, local_cleanup() called from
    nfc_llcp_unregister_device() frees local->rx_pending and decreases
    local->ref by kref_put() in nfc_llcp_local_put().
    In the terminating process, nfc daemon releases all sockets and it leads
    to decreasing local->ref. After the last release of local->ref,
    local_cleanup() called from local_release() frees local->rx_pending
    again, which leads to the bug.
    
    Setting local->rx_pending to NULL in local_cleanup() could prevent
    use-after-free when local_cleanup() is called twice.
    
    Found by a modified version of syzkaller.
    
    BUG: KASAN: use-after-free in kfree_skb()
    
    Call Trace:
    dump_stack_lvl (lib/dump_stack.c:106)
    print_address_description.constprop.0.cold (mm/kasan/report.c:306)
    kasan_check_range (mm/kasan/generic.c:189)
    kfree_skb (net/core/skbuff.c:955)
    local_cleanup (net/nfc/llcp_core.c:159)
    nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)
    nfc_llcp_local_put (net/nfc/llcp_core.c:181)
    llcp_sock_destruct (net/nfc/llcp_sock.c:959)
    __sk_destruct (net/core/sock.c:2133)
    sk_destruct (net/core/sock.c:2181)
    __sk_free (net/core/sock.c:2192)
    sk_free (net/core/sock.c:2203)
    llcp_sock_release (net/nfc/llcp_sock.c:646)
    __sock_release (net/socket.c:650)
    sock_close (net/socket.c:1365)
    __fput (fs/file_table.c:306)
    task_work_run (kernel/task_work.c:179)
    ptrace_notify (kernel/signal.c:2354)
    syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)
    syscall_exit_to_user_mode (kernel/entry/common.c:296)
    do_syscall_64 (arch/x86/entry/common.c:86)
    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)
    
    Allocated by task 4719:
    kasan_save_stack (mm/kasan/common.c:45)
    __kasan_slab_alloc (mm/kasan/common.c:325)
    slab_post_alloc_hook (mm/slab.h:766)
    kmem_cache_alloc_node (mm/slub.c:3497)
    __alloc_skb (net/core/skbuff.c:552)
    pn533_recv_response (drivers/nfc/pn533/usb.c:65)
    __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)
    usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)
    tasklet_action_common.isra.0 (kernel/softirq.c:797)
    __do_softirq (kernel/softirq.c:571)
    
    Freed by task 1901:
    kasan_save_stack (mm/kasan/common.c:45)
    kasan_set_track (mm/kasan/common.c:52)
    kasan_save_free_info (mm/kasan/genericdd.c:518)
    __kasan_slab_free (mm/kasan/common.c:236)
    kmem_cache_free (mm/slub.c:3809)
    kfree_skbmem (net/core/skbuff.c:874)
    kfree_skb (net/core/skbuff.c:931)
    local_cleanup (net/nfc/llcp_core.c:159)
    nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)
    nfc_unregister_device (net/nfc/core.c:1179)
    pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)
    pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)
    usb_unbind_interface (drivers/usb/core/driver.c:458)
    device_release_driver_internal (drivers/base/dd.c:1279)
    bus_remove_device (drivers/base/bus.c:529)
    device_del (drivers/base/core.c:3665)
    usb_disable_device (drivers/usb/core/message.c:1420)
    usb_disconnect (drivers/usb/core.c:2261)
    hub_event (drivers/usb/core/hub.c:5833)
    process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)
    worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)
    kthread (kernel/kthread.c:319)
    ret_from_fork (arch/x86/entry/entry_64.S:301)
    
    Fixes: 3536da06db0b ("NFC: llcp: Clean local timers and works when removing a device")
    Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
    Link: https://lore.kernel.org/r/20230111131914.3338838-1-jisoo.jang@yonsei.ac.kr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ravb: Fix lack of register setting after system resumed for Gen3 [+ + +]
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Jan 24 09:02:10 2023 +0900

    net: ravb: Fix lack of register setting after system resumed for Gen3
    
    [ Upstream commit c2b6cdee1d13ffbb24baca3c9b8a572d6b541e4e ]
    
    After system entered Suspend to RAM, registers setting of this
    hardware is reset because the SoC will be turned off. On R-Car Gen3
    (info->ccc_gac), ravb_ptp_init() is called in ravb_probe() only. So,
    after system resumed, it lacks of the initial settings for ptp. So,
    add ravb_ptp_{init,stop}() into ravb_{resume,suspend}().
    
    Fixes: f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ravb: Fix possible hang if RIS2_QFF1 happen [+ + +]
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Tue Jan 24 09:02:11 2023 +0900

    net: ravb: Fix possible hang if RIS2_QFF1 happen
    
    [ Upstream commit f3c07758c9007a6bfff5290d9e19d3c41930c897 ]
    
    Since this driver enables the interrupt by RIC2_QFE1, this driver
    should clear the interrupt flag if it happens. Otherwise, the interrupt
    causes to hang the system.
    
    Note that this also fix a minor coding style (a comment indentation)
    around the fixed code.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sched: gred: prevent races when adding offloads to stats [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Jan 12 20:41:37 2023 -0800

    net: sched: gred: prevent races when adding offloads to stats
    
    [ Upstream commit 339346d49ae0859fe19b860998867861d37f1a76 ]
    
    Naresh reports seeing a warning that gred is calling
    u64_stats_update_begin() with preemption enabled.
    Arnd points out it's coming from _bstats_update().
    
    We should be holding the qdisc lock when writing
    to stats, they are also updated from the datapath.
    
    Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Link: https://lore.kernel.org/all/CA+G9fYsTr9_r893+62u6UGD3dVaCE-kN9C-Apmb2m=hxjc1Cqg@mail.gmail.com/
    Fixes: e49efd5288bd ("net: sched: gred: support reporting stats from offloads")
    Link: https://lore.kernel.org/r/20230113044137.1383067-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: enable all safety features by default [+ + +]
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Wed Jan 18 10:56:38 2023 -0600

    net: stmmac: enable all safety features by default
    
    [ Upstream commit fdfc76a116b5e9d3e98e6c96fe83b42d011d21d4 ]
    
    In the original implementation of dwmac5
    commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")
    all safety features were enabled by default.
    
    Later it seems some implementations didn't have support for all the
    features, so in
    commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")
    the safety_feat_cfg structure was added to the callback and defined for
    some platforms to selectively enable these safety features.
    
    The problem is that only certain platforms were given that software
    support. If the automotive safety package bit is set in the hardware
    features register the safety feature callback is called for the platform,
    and for platforms that didn't get a safety_feat_cfg defined this results
    in the following NULL pointer dereference:
    
    [    7.933303] Call trace:
    [    7.935812]  dwmac5_safety_feat_config+0x20/0x170 [stmmac]
    [    7.941455]  __stmmac_open+0x16c/0x474 [stmmac]
    [    7.946117]  stmmac_open+0x38/0x70 [stmmac]
    [    7.950414]  __dev_open+0x100/0x1dc
    [    7.954006]  __dev_change_flags+0x18c/0x204
    [    7.958297]  dev_change_flags+0x24/0x6c
    [    7.962237]  do_setlink+0x2b8/0xfa4
    [    7.965827]  __rtnl_newlink+0x4ec/0x840
    [    7.969766]  rtnl_newlink+0x50/0x80
    [    7.973353]  rtnetlink_rcv_msg+0x12c/0x374
    [    7.977557]  netlink_rcv_skb+0x5c/0x130
    [    7.981500]  rtnetlink_rcv+0x18/0x2c
    [    7.985172]  netlink_unicast+0x2e8/0x340
    [    7.989197]  netlink_sendmsg+0x1a8/0x420
    [    7.993222]  ____sys_sendmsg+0x218/0x280
    [    7.997249]  ___sys_sendmsg+0xac/0x100
    [    8.001103]  __sys_sendmsg+0x84/0xe0
    [    8.004776]  __arm64_sys_sendmsg+0x24/0x30
    [    8.008983]  invoke_syscall+0x48/0x114
    [    8.012840]  el0_svc_common.constprop.0+0xcc/0xec
    [    8.017665]  do_el0_svc+0x38/0xb0
    [    8.021071]  el0_svc+0x2c/0x84
    [    8.024212]  el0t_64_sync_handler+0xf4/0x120
    [    8.028598]  el0t_64_sync+0x190/0x194
    
    Go back to the original behavior, if the automotive safety package
    is found to be supported in hardware enable all the features unless
    safety_feat_cfg is passed in saying this particular platform only
    supports a subset of the features.
    
    Fixes: 5ac712dcdfef ("net: stmmac: enable platform specific safety features")
    Reported-by: Ning Cai <ncai@quicinc.com>
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: fix invalid call to mdiobus_get_phy() [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 15 18:24:08 2023 +0100

    net: stmmac: fix invalid call to mdiobus_get_phy()
    
    [ Upstream commit 1f3bd64ad921f051254591fbed04fd30b306cde6 ]
    
    In a number of cases the driver assigns a default value of -1 to
    priv->plat->phy_addr. This may result in calling mdiobus_get_phy()
    with addr parameter being -1. Therefore check for this scenario and
    bail out before calling mdiobus_get_phy().
    
    Fixes: 42e87024f727 ("net: stmmac: Fix case when PHY handle is not present")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Link: https://lore.kernel.org/r/669f9671-ecd1-a41b-2727-7b73e3003985@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: Fix queue statistics reading [+ + +]
Author: Kurt Kanzenbach <kurt@linutronix.de>
Date:   Sat Jan 14 13:04:37 2023 +0100

    net: stmmac: Fix queue statistics reading
    
    [ Upstream commit c296c77efb66994d94d9f706446a115581226550 ]
    
    Correct queue statistics reading. All queue statistics are stored as unsigned
    long values. The retrieval for ethtool fetches these values as u64. However, on
    some systems the size of the counters are 32 bit. That yields wrong queue
    statistic counters e.g., on arm32 systems such as the stm32mp157. Fix it by
    using the correct data type.
    
    Tested on Olimex STMP157-OLinuXino-LIME2 by simple running linuxptp for a short
    period of time:
    
    Non-patched kernel:
    |root@st1:~# ethtool -S eth0 | grep q0
    |     q0_tx_pkt_n: 3775276254951 # ???
    |     q0_tx_irq_n: 879
    |     q0_rx_pkt_n: 1194000908909 # ???
    |     q0_rx_irq_n: 278
    
    Patched kernel:
    |root@st1:~# ethtool -S eth0 | grep q0
    |     q0_tx_pkt_n: 2434
    |     q0_tx_irq_n: 1274
    |     q0_rx_pkt_n: 1604
    |     q0_rx_irq_n: 846
    
    Fixes: 68e9c5dee1cf ("net: stmmac: add ethtool per-queue statistic framework")
    Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
    Cc: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
    Cc: Wong Vee Khee <vee.khee.wong@linux.intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: cdc_ether: add support for Thales Cinterion PLS62-W modem [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Thu Jan 5 11:42:49 2023 +0800

    net: usb: cdc_ether: add support for Thales Cinterion PLS62-W modem
    
    [ Upstream commit eea8ce81fbb544e3caad1a1c876ba1af467b3d3c ]
    
    This modem has 7 interfaces, 5 of them are serial interfaces and are
    driven by cdc_acm, while 2 of them are wwan interfaces and are driven
    by cdc_ether:
    If 0: Abstract (modem)
    If 1: Abstract (modem)
    If 2: Abstract (modem)
    If 3: Abstract (modem)
    If 4: Abstract (modem)
    If 5: Ethernet Networking
    If 6: Ethernet Networking
    
    Without this change, the 2 network interfaces will be named to usb0
    and usb1, our QA think the names are confusing and filed a bug on it.
    
    After applying this change, the name will be wwan0 and wwan1, and
    they could work well with modem manager.
    
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20230105034249.10433-1-hui.wang@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: usb: sr9700: Handle negative len [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Sat Jan 14 19:23:26 2023 +0100

    net: usb: sr9700: Handle negative len
    
    [ Upstream commit ecf7cf8efb59789e2b21d2f9ab926142579092b2 ]
    
    Packet len computed as difference of length word extracted from
    skb data and four may result in a negative value. In such case
    processing of the buffer should be interrupted rather than
    setting sr_skb->len to an unexpectedly large value (due to cast
    from signed to unsigned integer) and passing sr_skb to
    usbnet_skb_return.
    
    Fixes: e9da0b56fe27 ("sr9700: sanity check for packet length")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Link: https://lore.kernel.org/r/20230114182326.30479-1-szymon.heidrich@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs [+ + +]
Author: Esina Ekaterina <eesina@astralinux.ru>
Date:   Thu Jan 12 10:47:03 2023 +0300

    net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs
    
    [ Upstream commit 488e0bf7f34af3d42d1d5e56f7a5a7beaff188a3 ]
    
    If uhdlc_priv_tsa != 1 then utdm is not initialized.
    And if ret != NULL then goto undo_uhdlc_init, where
    utdm is dereferenced. Same if dev == NULL.
    
    Found by Astra Linux on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: 8d68100ab4ad ("soc/fsl/qe: fix err handling of ucc_of_parse_tdm")
    Signed-off-by: Esina Ekaterina <eesina@astralinux.ru>
    Link: https://lore.kernel.org/r/20230112074703.13558-1-eesina@astralinux.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE [+ + +]
Author: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
Date:   Tue Jan 24 02:47:18 2023 +0100

    netfilter: conntrack: fix vtag checks for ABORT/SHUTDOWN_COMPLETE
    
    [ Upstream commit a9993591fa94246b16b444eea55d84c54608282a ]
    
    RFC 9260, Sec 8.5.1 states that for ABORT/SHUTDOWN_COMPLETE, the chunk
    MUST be accepted if the vtag of the packet matches its own tag and the
    T bit is not set OR if it is set to its peer's vtag and the T bit is set
    in chunk flags. Otherwise the packet MUST be silently dropped.
    
    Update vtag verification for ABORT/SHUTDOWN_COMPLETE based on the above
    description.
    
    Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
    Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: conntrack: handle tcp challenge acks during connection reuse [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Jan 11 14:42:32 2023 +0100

    netfilter: conntrack: handle tcp challenge acks during connection reuse
    
    [ Upstream commit c410cb974f2ba562920ecb8492ee66945dcf88af ]
    
    When a connection is re-used, following can happen:
    [ connection starts to close, fin sent in either direction ]
     > syn   # initator quickly reuses connection
     < ack   # peer sends a challenge ack
     > rst   # rst, sequence number == ack_seq of previous challenge ack
     > syn   # this syn is expected to pass
    
    Problem is that the rst will fail window validation, so it gets
    tagged as invalid.
    
    If ruleset drops such packets, we get repeated syn-retransmits until
    initator gives up or peer starts responding with syn/ack.
    
    Before the commit indicated in the "Fixes" tag below this used to work:
    
    The challenge-ack made conntrack re-init state based on the challenge
    ack itself, so the following rst would pass window validation.
    
    Add challenge-ack support: If we get ack for syn, record the ack_seq,
    and then check if the rst sequence number matches the last ack number
    seen in reverse direction.
    
    Fixes: c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets only")
    Reported-by: Michal Tesar <mtesar@redhat.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: conntrack: unify established states for SCTP paths [+ + +]
Author: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
Date:   Tue Jan 24 02:47:21 2023 +0100

    netfilter: conntrack: unify established states for SCTP paths
    
    commit a44b7651489f26271ac784b70895e8a85d0cebf4 upstream.
    
    An SCTP endpoint can start an association through a path and tear it
    down over another one. That means the initial path will not see the
    shutdown sequence, and the conntrack entry will remain in ESTABLISHED
    state for 5 days.
    
    By merging the HEARTBEAT_ACKED and ESTABLISHED states into one
    ESTABLISHED state, there remains no difference between a primary or
    secondary path. The timeout for the merged ESTABLISHED state is set to
    210 seconds (hb_interval * max_path_retrans + rto_max). So, even if a
    path doesn't see the shutdown sequence, it will expire in a reasonable
    amount of time.
    
    With this change in place, there is now more than one state from which
    we can transition to ESTABLISHED, COOKIE_ECHOED and HEARTBEAT_SENT, so
    handle the setting of ASSURED bit whenever a state change has happened
    and the new state is ESTABLISHED. Removed the check for dir==REPLY since
    the transition to ESTABLISHED can happen only in the reply direction.
    
    Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
    Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nft_set_rbtree: skip elements in transaction from garbage collection [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jan 14 23:49:46 2023 +0100

    netfilter: nft_set_rbtree: skip elements in transaction from garbage collection
    
    [ Upstream commit 5d235d6ce75c12a7fdee375eb211e4116f7ab01b ]
    
    Skip interference with an ongoing transaction, do not perform garbage
    collection on inactive elements. Reset annotated previous end interval
    if the expired element is marked as busy (control plane removed the
    element right before expiration).
    
    Fixes: 8d8540c4f5e0 ("netfilter: nft_set_rbtree: add timeout support")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_set_rbtree: Switch to node list walk for overlap detection [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Sat Jan 14 23:38:32 2023 +0100

    netfilter: nft_set_rbtree: Switch to node list walk for overlap detection
    
    [ Upstream commit c9e6978e2725a7d4b6cd23b2facd3f11422c0643 ]
    
    ...instead of a tree descent, which became overly complicated in an
    attempt to cover cases where expired or inactive elements would affect
    comparisons with the new element being inserted.
    
    Further, it turned out that it's probably impossible to cover all those
    cases, as inactive nodes might entirely hide subtrees consisting of a
    complete interval plus a node that makes the current insertion not
    overlap.
    
    To speed up the overlap check, descent the tree to find a greater
    element that is closer to the key value to insert. Then walk down the
    node list for overlap detection. Starting the overlap check from
    rb_first() unconditionally is slow, it takes 10 times longer due to the
    full linear traversal of the list.
    
    Moreover, perform garbage collection of expired elements when walking
    down the node list to avoid bogus overlap reports.
    
    For the insertion operation itself, this essentially reverts back to the
    implementation before commit 7c84d41416d8 ("netfilter: nft_set_rbtree:
    Detect partial overlaps on insertion"), except that cases of complete
    overlap are already handled in the overlap detection phase itself, which
    slightly simplifies the loop to find the insertion point.
    
    Based on initial patch from Stefano Brivio, including text from the
    original patch description too.
    
    Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion")
    Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netlink: annotate data races around dst_portid and dst_group [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:54 2023 +0000

    netlink: annotate data races around dst_portid and dst_group
    
    [ Upstream commit 004db64d185a5f23dfb891d7701e23713b2420ee ]
    
    netlink_getname(), netlink_sendmsg() and netlink_getsockbyportid()
    can read nlk->dst_portid and nlk->dst_group while another
    thread is changing them.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: annotate data races around nlk->portid [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:53 2023 +0000

    netlink: annotate data races around nlk->portid
    
    [ Upstream commit c1bb9484e3b05166880da8574504156ccbd0549e ]
    
    syzbot reminds us netlink_getname() runs locklessly [1]
    
    This first patch annotates the race against nlk->portid.
    
    Following patches take care of the remaining races.
    
    [1]
    BUG: KCSAN: data-race in netlink_getname / netlink_insert
    
    write to 0xffff88814176d310 of 4 bytes by task 2315 on cpu 1:
    netlink_insert+0xf1/0x9a0 net/netlink/af_netlink.c:583
    netlink_autobind+0xae/0x180 net/netlink/af_netlink.c:856
    netlink_sendmsg+0x444/0x760 net/netlink/af_netlink.c:1895
    sock_sendmsg_nosec net/socket.c:714 [inline]
    sock_sendmsg net/socket.c:734 [inline]
    ____sys_sendmsg+0x38f/0x500 net/socket.c:2476
    ___sys_sendmsg net/socket.c:2530 [inline]
    __sys_sendmsg+0x19a/0x230 net/socket.c:2559
    __do_sys_sendmsg net/socket.c:2568 [inline]
    __se_sys_sendmsg net/socket.c:2566 [inline]
    __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    read to 0xffff88814176d310 of 4 bytes by task 2316 on cpu 0:
    netlink_getname+0xcd/0x1a0 net/netlink/af_netlink.c:1144
    __sys_getsockname+0x11d/0x1b0 net/socket.c:2026
    __do_sys_getsockname net/socket.c:2041 [inline]
    __se_sys_getsockname net/socket.c:2038 [inline]
    __x64_sys_getsockname+0x3e/0x50 net/socket.c:2038
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    value changed: 0x00000000 -> 0xc9a49780
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 2316 Comm: syz-executor.2 Not tainted 6.2.0-rc3-syzkaller-00030-ge8f60cd7db24-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: annotate data races around sk_state [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 20 12:59:55 2023 +0000

    netlink: annotate data races around sk_state
    
    [ Upstream commit 9b663b5cbb15b494ef132a3c937641c90646eb73 ]
    
    netlink_getsockbyportid() reads sk_state while a concurrent
    netlink_connect() can change its value.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netlink: prevent potential spectre v1 gadgets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jan 19 11:01:50 2023 +0000

    netlink: prevent potential spectre v1 gadgets
    
    [ Upstream commit f0950402e8c76e7dcb08563f1b4e8000fbc62455 ]
    
    Most netlink attributes are parsed and validated from
    __nla_validate_parse() or validate_nla()
    
        u16 type = nla_type(nla);
    
        if (type == 0 || type > maxtype) {
            /* error or continue */
        }
    
    @type is then used as an array index and can be used
    as a Spectre v1 gadget.
    
    array_index_nospec() can be used to prevent leaking
    content of kernel memory to malicious users.
    
    This should take care of vast majority of netlink uses,
    but an audit is needed to take care of others where
    validation is not yet centralized in core netlink functions.
    
    Fixes: bfa83a9e03cf ("[NETLINK]: Type-safe netlink messages/attributes interface")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Link: https://lore.kernel.org/r/20230119110150.2678537-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netrom: Fix use-after-free of a listening socket. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Fri Jan 20 15:19:27 2023 -0800

    netrom: Fix use-after-free of a listening socket.
    
    [ Upstream commit 409db27e3a2eb5e8ef7226ca33be33361b3ed1c9 ]
    
    syzbot reported a use-after-free in do_accept(), precisely nr_accept()
    as sk_prot_alloc() allocated the memory and sock_put() frees it. [0]
    
    The issue could happen if the heartbeat timer is fired and
    nr_heartbeat_expiry() calls nr_destroy_socket(), where a socket
    has SOCK_DESTROY or a listening socket has SOCK_DEAD.
    
    In this case, the first condition cannot be true.  SOCK_DESTROY is
    flagged in nr_release() only when the file descriptor is close()d,
    but accept() is being called for the listening socket, so the second
    condition must be true.
    
    Usually, the AF_NETROM listener neither starts timers nor sets
    SOCK_DEAD.  However, the condition is met if connect() fails before
    listen().  connect() starts the t1 timer and heartbeat timer, and
    t1timer calls nr_disconnect() when timeout happens.  Then, SOCK_DEAD
    is set, and if we call listen(), the heartbeat timer calls
    nr_destroy_socket().
    
      nr_connect
        nr_establish_data_link(sk)
          nr_start_t1timer(sk)
        nr_start_heartbeat(sk)
                                        nr_t1timer_expiry
                                          nr_disconnect(sk, ETIMEDOUT)
                                            nr_sk(sk)->state = NR_STATE_0
                                            sk->sk_state = TCP_CLOSE
                                            sock_set_flag(sk, SOCK_DEAD)
    nr_listen
      if (sk->sk_state != TCP_LISTEN)
        sk->sk_state = TCP_LISTEN
                                        nr_heartbeat_expiry
                                          switch (nr->state)
                                          case NR_STATE_0
                                            if (sk->sk_state == TCP_LISTEN &&
                                                sock_flag(sk, SOCK_DEAD))
                                              nr_destroy_socket(sk)
    
    This path seems expected, and nr_destroy_socket() is called to clean
    up resources.  Initially, there was sock_hold() before nr_destroy_socket()
    so that the socket would not be freed, but the commit 517a16b1a88b
    ("netrom: Decrease sock refcount when sock timers expire") accidentally
    removed it.
    
    To fix use-after-free, let's add sock_hold().
    
    [0]:
    BUG: KASAN: use-after-free in do_accept+0x483/0x510 net/socket.c:1848
    Read of size 8 at addr ffff88807978d398 by task syz-executor.3/5315
    
    CPU: 0 PID: 5315 Comm: syz-executor.3 Not tainted 6.2.0-rc3-syzkaller-00165-gd9fc1511728c #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:306 [inline]
     print_report+0x15e/0x461 mm/kasan/report.c:417
     kasan_report+0xbf/0x1f0 mm/kasan/report.c:517
     do_accept+0x483/0x510 net/socket.c:1848
     __sys_accept4_file net/socket.c:1897 [inline]
     __sys_accept4+0x9a/0x120 net/socket.c:1927
     __do_sys_accept net/socket.c:1944 [inline]
     __se_sys_accept net/socket.c:1941 [inline]
     __x64_sys_accept+0x75/0xb0 net/socket.c:1941
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fa436a8c0c9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fa437784168 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
    RAX: ffffffffffffffda RBX: 00007fa436bac050 RCX: 00007fa436a8c0c9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
    RBP: 00007fa436ae7ae9 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffebc6700df R14: 00007fa437784300 R15: 0000000000022000
     </TASK>
    
    Allocated by task 5294:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     ____kasan_kmalloc mm/kasan/common.c:371 [inline]
     ____kasan_kmalloc mm/kasan/common.c:330 [inline]
     __kasan_kmalloc+0xa3/0xb0 mm/kasan/common.c:380
     kasan_kmalloc include/linux/kasan.h:211 [inline]
     __do_kmalloc_node mm/slab_common.c:968 [inline]
     __kmalloc+0x5a/0xd0 mm/slab_common.c:981
     kmalloc include/linux/slab.h:584 [inline]
     sk_prot_alloc+0x140/0x290 net/core/sock.c:2038
     sk_alloc+0x3a/0x7a0 net/core/sock.c:2091
     nr_create+0xb6/0x5f0 net/netrom/af_netrom.c:433
     __sock_create+0x359/0x790 net/socket.c:1515
     sock_create net/socket.c:1566 [inline]
     __sys_socket_create net/socket.c:1603 [inline]
     __sys_socket_create net/socket.c:1588 [inline]
     __sys_socket+0x133/0x250 net/socket.c:1636
     __do_sys_socket net/socket.c:1649 [inline]
     __se_sys_socket net/socket.c:1647 [inline]
     __x64_sys_socket+0x73/0xb0 net/socket.c:1647
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Freed by task 14:
     kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:518
     ____kasan_slab_free mm/kasan/common.c:236 [inline]
     ____kasan_slab_free+0x13b/0x1a0 mm/kasan/common.c:200
     kasan_slab_free include/linux/kasan.h:177 [inline]
     __cache_free mm/slab.c:3394 [inline]
     __do_kmem_cache_free mm/slab.c:3580 [inline]
     __kmem_cache_free+0xcd/0x3b0 mm/slab.c:3587
     sk_prot_free net/core/sock.c:2074 [inline]
     __sk_destruct+0x5df/0x750 net/core/sock.c:2166
     sk_destruct net/core/sock.c:2181 [inline]
     __sk_free+0x175/0x460 net/core/sock.c:2192
     sk_free+0x7c/0xa0 net/core/sock.c:2203
     sock_put include/net/sock.h:1991 [inline]
     nr_heartbeat_expiry+0x1d7/0x460 net/netrom/nr_timer.c:148
     call_timer_fn+0x1da/0x7c0 kernel/time/timer.c:1700
     expire_timers+0x2c6/0x5c0 kernel/time/timer.c:1751
     __run_timers kernel/time/timer.c:2022 [inline]
     __run_timers kernel/time/timer.c:1995 [inline]
     run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
     __do_softirq+0x1fb/0xadc kernel/softirq.c:571
    
    Fixes: 517a16b1a88b ("netrom: Decrease sock refcount when sock timers expire")
    Reported-by: syzbot+5fafd5cfe1fc91f6b352@syzkaller.appspotmail.com
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/r/20230120231927.51711-1-kuniyu@amazon.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfsd: don't free files unconditionally in __nfsd_file_cache_purge [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Jan 20 14:52:14 2023 -0500

    nfsd: don't free files unconditionally in __nfsd_file_cache_purge
    
    [ Upstream commit 4bdbba54e9b1c769da8ded9abd209d765715e1d6 ]
    
    nfsd_file_cache_purge is called when the server is shutting down, in
    which case, tearing things down is generally fine, but it also gets
    called when the exports cache is flushed.
    
    Instead of walking the cache and freeing everything unconditionally,
    handle it the same as when we have a notification of conflicting access.
    
    Fixes: ac3a2585f018 ("nfsd: rework refcounting in filecache")
    Reported-by: Ruben Vestergaard <rubenv@drcmr.dk>
    Reported-by: Torkil Svensgaard <torkil@drcmr.dk>
    Reported-by: Shachar Kagan <skagan@nvidia.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Shachar Kagan <skagan@nvidia.com>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: fix use-after-free in nfsd4_ssc_setup_dul() [+ + +]
Author: Xingyuan Mo <hdthky0@gmail.com>
Date:   Thu Jan 12 00:24:53 2023 +0800

    NFSD: fix use-after-free in nfsd4_ssc_setup_dul()
    
    [ Upstream commit e6cf91b7b47ff82b624bdfe2fdcde32bb52e71dd ]
    
    If signal_pending() returns true, schedule_timeout() will not be executed,
    causing the waiting task to remain in the wait queue.
    Fixed by adding a call to finish_wait(), which ensures that the waiting
    task will always be removed from the wait queue.
    
    Fixes: f4e44b393389 ("NFSD: delay unmount source's export after inter-server copy completed.")
    Signed-off-by: Xingyuan Mo <hdthky0@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nolibc: fix fd_set type [+ + +]
Author: Sven Schnelle <svens@linux.ibm.com>
Date:   Mon Jan 9 08:54:37 2023 +0100

    nolibc: fix fd_set type
    
    [ Upstream commit feaf75658783a919410f8c2039dbc24b6a29603d ]
    
    The kernel uses unsigned long for the fd_set bitmap,
    but nolibc use u32. This works fine on little endian
    machines, but fails on big endian. Convert to unsigned
    long to fix this.
    
    Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-fc: fix initialization order [+ + +]
Author: Ross Lagerwall <ross.lagerwall@citrix.com>
Date:   Fri Jan 20 17:43:54 2023 +0000

    nvme-fc: fix initialization order
    
    [ Upstream commit 98e3528012cd571c48bbae7c7c0f868823254b6c ]
    
    ctrl->ops is used by nvme_alloc_admin_tag_set() but set by
    nvme_init_ctrl() so reorder the calls to avoid a NULL pointer
    dereference.
    
    Fixes: 6dfba1c09c10 ("nvme-fc: use the tagset alloc/free helpers")
    Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-pci: fix timeout request state check [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Wed Jan 18 08:44:16 2023 -0800

    nvme-pci: fix timeout request state check
    
    [ Upstream commit 1c5842085851f786eba24a39ecd02650ad892064 ]
    
    Polling the completion can progress the request state to IDLE, either
    inline with the completion, or through softirq. Either way, the state
    may not be COMPLETED, so don't check for that. We only care if the state
    isn't IN_FLIGHT.
    
    This is fixing an issue where the driver aborts an IO that we just
    completed. Seeing the "aborting" message instead of "polled" is very
    misleading as to where the timeout problem resides.
    
    Fixes: bf392a5dc02a9b ("nvme-pci: Remove tag from process cq")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: consolidate setting the tagset flags [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Nov 30 17:19:50 2022 +0100

    nvme: consolidate setting the tagset flags
    
    [ Upstream commit db45e1a5ddccc034eb60d62fc5352022d7963ae2 ]
    
    All nvme transports should be using the same flags for their tagsets,
    with the exception for the blocking flag that should only be set for
    transports that can block in ->queue_rq.
    
    Add a NVME_F_BLOCKING flag to nvme_ctrl_ops to control the blocking
    behavior and lift setting the flags into nvme_alloc_{admin,io}_tag_set.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Stable-dep-of: 98e3528012cd ("nvme-fc: fix initialization order")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: fix passthrough csi check [+ + +]
Author: Keith Busch <kbusch@kernel.org>
Date:   Tue Jan 24 13:29:14 2023 -0800

    nvme: fix passthrough csi check
    
    [ Upstream commit 85eee6341abb81ac6a35062ffd5c3029eb53be6b ]
    
    The namespace head saves the Command Set Indicator enum, so use that
    instead of the Command Set Selected. The two values are not the same.
    
    Fixes: 831ed60c2aca2d ("nvme: also return I/O command effects from nvme_command_effects")
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: simplify transport specific device attribute handling [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Oct 27 02:34:13 2022 -0700

    nvme: simplify transport specific device attribute handling
    
    [ Upstream commit 86adbf0cdb9ec6533234696c3e243184d4d0d040 ]
    
    Allow the transport driver to override the attribute groups for the
    control device, so that the PCIe driver doesn't manually have to add a
    group after device creation and keep track of it.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Tested-by Gerd Bayer <gbayer@linxu.ibm.com>
    Stable-dep-of: 98e3528012cd ("nvme-fc: fix initialization order")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: fail on invalid uid/gid mapping at copy up [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jan 24 16:41:18 2023 +0100

    ovl: fail on invalid uid/gid mapping at copy up
    
    commit 4f11ada10d0ad3fd53e2bd67806351de63a4f9c3 upstream.
    
    If st_uid/st_gid doesn't have a mapping in the mounter's user_ns, then
    copy-up should fail, just like it would fail if the mounter task was doing
    the copy using "cp -a".
    
    There's a corner case where the "cp -a" would succeed but copy up fail: if
    there's a mapping of the invalid uid/gid (65534 by default) in the user
    namespace.  This is because stat(2) will return this value if the mapping
    doesn't exist in the current user_ns and "cp -a" will in turn be able to
    create a file with this uid/gid.
    
    This behavior would be inconsistent with POSIX ACL's, which return -1 for
    invalid uid/gid which result in a failed copy.
    
    For consistency and simplicity fail the copy of the st_uid/st_gid are
    invalid.
    
    Fixes: 459c7c565ac3 ("ovl: unprivieged mounts")
    Cc: <stable@vger.kernel.org> # v5.11
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Reviewed-by: Christian Brauner <brauner@kernel.org>
    Reviewed-by: Seth Forshee <sforshee@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ovl: fix tmpfile leak [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Jan 24 16:41:18 2023 +0100

    ovl: fix tmpfile leak
    
    commit baabaa505563362b71f2637aedd7b807d270656c upstream.
    
    Missed an error cleanup.
    
    Reported-by: syzbot+fd749a7ea127a84e0ffd@syzkaller.appspotmail.com
    Fixes: 2b1a77461f16 ("ovl: use vfs_tmpfile_open() helper")
    Cc: <stable@vger.kernel.org> # v6.1
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Partially revert "perf/arm-cmn: Optimise DTC counter accesses" [+ + +]
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Mon Jan 23 18:30:38 2023 +0000

    Partially revert "perf/arm-cmn: Optimise DTC counter accesses"
    
    [ Upstream commit a428eb4b99ab80454f06ad256b25e930fe8a4954 ]
    
    It turns out the optimisation implemented by commit 4f2c3872dde5 is
    totally broken, since all the places that consume hw->dtcs_used for
    events other than cycle count are still not expecting it to be sparsely
    populated, and fail to read all the relevant DTC counters correctly if
    so.
    
    If implemented correctly, the optimisation potentially saves up to 3
    register reads per event update, which is reasonably significant for
    events targeting a single node, but still not worth a massive amount of
    additional code complexity overall. Getting it right within the current
    design looks a fair bit more involved than it was ever intended to be,
    so let's just make a functional revert which restores the old behaviour
    while still backporting easily.
    
    Fixes: 4f2c3872dde5 ("perf/arm-cmn: Optimise DTC counter accesses")
    Reported-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
    Signed-off-by: Robin Murphy <robin.murphy@arm.com>
    Link: https://lore.kernel.org/r/b41bb4ed7283c3d8400ce5cf5e6ec94915e6750f.1674498637.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/amd: fix potential integer overflow on shift of a int [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Fri Dec 2 13:51:49 2022 +0000

    perf/x86/amd: fix potential integer overflow on shift of a int
    
    commit 08245672cdc6505550d1a5020603b0a8d4a6dcc7 upstream.
    
    The left shift of int 32 bit integer constant 1 is evaluated using 32 bit
    arithmetic and then passed as a 64 bit function argument. In the case where
    i is 32 or more this can lead to an overflow.  Avoid this by shifting
    using the BIT_ULL macro instead.
    
    Fixes: 471af006a747 ("perf/x86/amd: Constrain Large Increment per Cycle events")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Acked-by: Kim Phillips <kim.phillips@amd.com>
    Link: https://lore.kernel.org/r/20221202135149.1797974-1-colin.i.king@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf/x86/cstate: Add Meteor Lake support [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed Jan 4 12:13:46 2023 -0800

    perf/x86/cstate: Add Meteor Lake support
    
    [ Upstream commit 01f2ea5bcf89dbd7a6530dbce7f2fb4e327e7006 ]
    
    Meteor Lake is Intel's successor to Raptor lake. From the perspective of
    Intel cstate residency counters, there is nothing changed compared with
    Raptor lake.
    
    Share adl_cstates with Raptor lake.
    Update the comments for Meteor Lake.
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Link: https://lore.kernel.org/r/20230104201349.1451191-6-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/intel/uncore: Add Emerald Rapids [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Fri Jan 6 08:04:49 2023 -0800

    perf/x86/intel/uncore: Add Emerald Rapids
    
    [ Upstream commit 5268a2842066c227e6ccd94bac562f1e1000244f ]
    
    From the perspective of the uncore PMU, the new Emerald Rapids is the
    same as the Sapphire Rapids. The only difference is the event list,
    which will be supported in the perf tool later.
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20230106160449.3566477-4-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/msr: Add Emerald Rapids [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Fri Jan 6 08:04:48 2023 -0800

    perf/x86/msr: Add Emerald Rapids
    
    [ Upstream commit 69ced4160969025821f2999ff92163ed26568f1c ]
    
    The same as Sapphire Rapids, the SMI_COUNT MSR is also supported on
    Emerald Rapids. Add Emerald Rapids model.
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20230106160449.3566477-3-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf/x86/msr: Add Meteor Lake support [+ + +]
Author: Kan Liang <kan.liang@linux.intel.com>
Date:   Wed Jan 4 12:13:47 2023 -0800

    perf/x86/msr: Add Meteor Lake support
    
    [ Upstream commit 6887a4d3aede084bf08b70fbc9736c69fce05d7f ]
    
    Meteor Lake is Intel's successor to Raptor lake. PPERF and SMI_COUNT MSRs
    are also supported.
    
    Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Reviewed-by: Andi Kleen <ak@linux.intel.com>
    Link: https://lore.kernel.org/r/20230104201349.1451191-7-kan.liang@linux.intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: phy-can-transceiver: Skip warning if no "max-bitrate" [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Jan 18 11:29:58 2023 +0100

    phy: phy-can-transceiver: Skip warning if no "max-bitrate"
    
    [ Upstream commit bc30c15f275484f9b9fe27c2fa0895f3022d9943 ]
    
    According to the DT bindings, the "max-bitrate" property is optional.
    However, when it is not present, a warning is printed.
    Fix this by adding a missing check for -EINVAL.
    
    Fixes: a4a86d273ff1b6f7 ("phy: phy-can-transceiver: Add support for generic CAN transceiver driver")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/88e158f97dd52ebaa7126cd9631f34764b9c0795.1674037334.git.geert+renesas@glider.be
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: rockchip-inno-usb2: Fix missing clk_disable_unprepare() in rockchip_usb2phy_power_on() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Mon Dec 5 19:58:23 2022 +0800

    phy: rockchip-inno-usb2: Fix missing clk_disable_unprepare() in rockchip_usb2phy_power_on()
    
    [ Upstream commit 5daba914da0e48950e9407ea4d75fa57029c9adc ]
    
    The clk_disable_unprepare() should be called in the error handling of
    rockchip_usb2phy_power_on().
    
    Fixes: 0e08d2a727e6 ("phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Link: https://lore.kernel.org/r/20221205115823.16957-1-shangxiaojing@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: ti: fix Kconfig warning and operator precedence [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Mon Jan 9 22:25:29 2023 -0800

    phy: ti: fix Kconfig warning and operator precedence
    
    [ Upstream commit 7124c93887cc4e6c5b48920f83115e4a5892e870 ]
    
    Fix Kconfig depends operator precedence to prevent a Kconfig warning:
    
    WARNING: unmet direct dependencies detected for MUX_MMIO
      Depends on [n]: MULTIPLEXER [=m] && OF [=n]
      Selected by [m]:
      - PHY_AM654_SERDES [=m] && (OF [=n] && ARCH_K3 || COMPILE_TEST [=y]) && COMMON_CLK [=y]
    
    Fixes: 71e2f5c5c224 ("phy: ti: Add a new SERDES driver for TI's AM654x SoC")
    Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: Kishon Vijay Abraham I <kishon@kernel.org>
    Cc: linux-phy@lists.infradead.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20230110062529.22668-1-rdunlap@infradead.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: usb: sunplus: Fix potential null-ptr-deref in sp_usb_phy_probe() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Fri Nov 25 10:12:22 2022 +0800

    phy: usb: sunplus: Fix potential null-ptr-deref in sp_usb_phy_probe()
    
    [ Upstream commit 17eee264ef386ef30a69dd70e36f29893b85c170 ]
    
    sp_usb_phy_probe() will call platform_get_resource_byname() that may fail
    and return NULL. devm_ioremap() will use usbphy->moon4_res_mem->start as
    input, which may causes null-ptr-deref. Check the ret value of
    platform_get_resource_byname() to avoid the null-ptr-deref.
    
    Fixes: 99d9ccd97385 ("phy: usb: Add USB2.0 phy driver for Sunplus SP7021")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Link: https://lore.kernel.org/r/20221125021222.25687-1-shangxiaojing@huawei.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: rockchip: fix mux route data for rk3568 [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Tue Jan 10 08:46:53 2023 +0000

    pinctrl: rockchip: fix mux route data for rk3568
    
    [ Upstream commit 431d1531466033909d2e8c754a7dc3704b70843f ]
    
    IO mux selection is configured in PMU_GRF_SOC_CON4 and GRF_IOFUNC_SEL0-5
    regs on RK3568. pwm0-2 is configured in PMU_GRF reg and the rest is
    configured in GRF_IOFUNC regs according to TRM [1].
    
    Update mux route data to reflect this and use proper detection pin for
    UART1 IO mux M1.
    
    This fixes HDMITX IO mux M1 selection and makes it possible to enable
    HDMI CEC on my Radxa ROCK 3 Model A v1.31 board.
    
    [1] http://opensource.rock-chips.com/images/2/26/Rockchip_RK3568_TRM_Part1_V1.3-20220930P.PDF
    
    Fixes: c0dadc0e47a8 ("pinctrl: rockchip: add support for rk3568")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Link: https://lore.kernel.org/r/20230110084636.1141740-1-jonas@kwiboo.se
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pinctrl: rockchip: fix reading pull type on rk3568 [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Tue Jan 10 17:29:58 2023 +0000

    pinctrl: rockchip: fix reading pull type on rk3568
    
    [ Upstream commit 31b62a98de42cf65d76e4dcfb571af067d27d83a ]
    
    When reading pinconf-pins from debugfs it fails to get the configured pull
    type on RK3568, "unsupported pinctrl type" error messages is also reported.
    
    Fix this by adding support for RK3568 in rockchip_get_pull, including a
    reverse of the pull-up value swap applied in rockchip_set_pull so that
    pull-up is correctly reported in pinconf-pins.
    Also update the workaround comment to reflect affected pins, GPIO0_D3-D6.
    
    Fixes: c0dadc0e47a8 ("pinctrl: rockchip: add support for rk3568")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Reviewed-by: Jianqun Xu <jay.xu@rock-chips.com>
    Link: https://lore.kernel.org/r/20230110172955.1258840-1-jonas@kwiboo.se
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: apple-gmux: Add apple_gmux_detect() helper [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jan 24 11:57:53 2023 +0100

    platform/x86: apple-gmux: Add apple_gmux_detect() helper
    
    [ Upstream commit d143908f80f3e5d164ac3342f73d6b9f536e8b4d ]
    
    Add a new (static inline) apple_gmux_detect() helper to apple-gmux.h
    which can be used for gmux detection instead of apple_gmux_present().
    
    The latter is not really reliable since an ACPI device with a HID
    of APP000B is present on some devices without a gmux at all, as well
    as on devices with a newer (unsupported) MMIO based gmux model.
    
    This causes apple_gmux_present() to return false-positives on
    a number of different Apple laptop models.
    
    This new helper uses the same probing as the actual apple-gmux
    driver, so that it does not return false positives.
    
    To avoid code duplication the gmux_probe() function of the actual
    driver is also moved over to using the new apple_gmux_detect() helper.
    
    This avoids false positives (vs _HID + IO region detection) on:
    
    MacBookPro5,4
    https://pastebin.com/8Xjq7RhS
    
    MacBookPro8,1
    https://linux-hardware.org/?probe=e513cfbadb&log=dmesg
    
    MacBookPro9,2
    https://bugzilla.kernel.org/attachment.cgi?id=278961
    
    MacBookPro10,2
    https://lkml.org/lkml/2014/9/22/657
    
    MacBookPro11,2
    https://forums.fedora-fr.org/viewtopic.php?id=70142
    
    MacBookPro11,4
    https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/master/test-16/dmesg
    
    Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
    Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/
    Reported-by: Emmanouil Kouroupakis <kartebi@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230124105754.62167-3-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: apple-gmux: Move port defines to apple-gmux.h [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Jan 24 11:57:52 2023 +0100

    platform/x86: apple-gmux: Move port defines to apple-gmux.h
    
    [ Upstream commit 39f5a81f7ad80eb3fbcbfd817c6552db9de5504d ]
    
    This is a preparation patch for adding a new static inline
    apple_gmux_detect() helper which actually checks a supported
    gmux is present, rather then only checking an ACPI device with
    the HID is there as apple_gmux_present() does.
    
    Fixes: 21245df307cb ("ACPI: video: Add Apple GMUX brightness control detection")
    Link: https://lore.kernel.org/platform-driver-x86/20230123113750.462144-1-hdegoede@redhat.com/
    Reported-by: Emmanouil Kouroupakis <kartebi@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230124105754.62167-2-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-nb-wmi: Add alternate mapping for KEY_CAMERA [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Wed Dec 21 03:49:59 2022 +0000

    platform/x86: asus-nb-wmi: Add alternate mapping for KEY_CAMERA
    
    [ Upstream commit c78a4e191839edc1e8c3e51565cf2e71d40e8883 ]
    
    This keycode is emitted on a Asus VivoBook E410MAB with firmware
    E410MAB.304.
    
    The physical key has a strikken-through camera printed on it.
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20221216-asus-key-v1-1-45da124119a3@weissschuh.net
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-nb-wmi: Add alternate mapping for KEY_SCREENLOCK [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Jan 12 19:18:41 2023 +0100

    platform/x86: asus-nb-wmi: Add alternate mapping for KEY_SCREENLOCK
    
    [ Upstream commit db9494895b405bf318dc7e563dee6daa51b3b6ed ]
    
    The 0x33 keycode is emitted by Fn + F6 on a ASUS FX705GE laptop.
    
    Reported-by: Nemcev Aleksey <Nemcev_Aleksey@inbox.ru>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230112181841.84652-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-wmi: Add quirk wmi_ignore_fan [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Wed Dec 21 17:59:49 2022 +0000

    platform/x86: asus-wmi: Add quirk wmi_ignore_fan
    
    [ Upstream commit c874b6de4cdfa2822a07b479887cd5f87fb5d078 ]
    
    Some laptops have a fan device listed in their ACPI tables but do not
    actually contain a fan.
    Introduce a quirk that can be used to override the fan detection logic.
    
    This was observed with a ASUS VivoBook E410MA running firmware
    E410MAB.304.
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20221221-asus-fan-v1-1-e07f3949725b@weissschuh.net
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-wmi: Fix kbd_dock_devid tablet-switch reporting [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Jan 20 15:34:41 2023 +0100

    platform/x86: asus-wmi: Fix kbd_dock_devid tablet-switch reporting
    
    [ Upstream commit fdcc0602d64f22185f61c70747214b630049cc33 ]
    
    Commit 1ea0d3b46798 ("platform/x86: asus-wmi: Simplify tablet-mode-switch
    handling") unified the asus-wmi tablet-switch handling, but it did not take
    into account that the value returned for the kbd_dock_devid WMI method is
    inverted where as the other ones are not inverted.
    
    This causes asus-wmi to report an inverted tablet-switch state for devices
    which use the kbd_dock_devid, which causes libinput to ignore touchpad
    events while the affected T10x model 2-in-1s are docked.
    
    Add inverting of the return value in the kbd_dock_devid case to fix this.
    
    Fixes: 1ea0d3b46798 ("platform/x86: asus-wmi: Simplify tablet-mode-switch handling")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20230120143441.527334-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: asus-wmi: Ignore fan on E410MA [+ + +]
Author: Thomas Weißschuh <linux@weissschuh.net>
Date:   Wed Dec 21 17:59:50 2022 +0000

    platform/x86: asus-wmi: Ignore fan on E410MA
    
    [ Upstream commit 82cc5c6c624c63f7b57214e325e2ea685d924e89 ]
    
    The ASUS VivoBook has a fan device described in its ACPI tables but does
    not actually contain any physical fan.
    Use the quirk to inhibit fan handling.
    
    Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
    Link: https://lore.kernel.org/r/20221221-asus-fan-v1-2-e07f3949725b@weissschuh.net
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: simatic-ipc: add another model [+ + +]
Author: Henning Schild <henning.schild@siemens.com>
Date:   Thu Dec 22 11:37:20 2022 +0100

    platform/x86: simatic-ipc: add another model
    
    [ Upstream commit d348b1d761e358a4ba03fb34aa7e3dbd278db236 ]
    
    Add IPC PX-39A support.
    
    Signed-off-by: Henning Schild <henning.schild@siemens.com>
    Link: https://lore.kernel.org/r/20221222103720.8546-3-henning.schild@siemens.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: simatic-ipc: correct name of a model [+ + +]
Author: Henning Schild <henning.schild@siemens.com>
Date:   Thu Dec 22 11:37:19 2022 +0100

    platform/x86: simatic-ipc: correct name of a model
    
    [ Upstream commit ed058eab22d64c00663563e8e1e112989c65c59f ]
    
    What we called IPC427G should be renamed to BX-39A to be more in line
    with the actual product name.
    
    Signed-off-by: Henning Schild <henning.schild@siemens.com>
    Link: https://lore.kernel.org/r/20221222103720.8546-2-henning.schild@siemens.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: thinkpad_acpi: Fix profile modes on Intel platforms [+ + +]
Author: Mark Pearson <mpearson-lenovo@squebb.ca>
Date:   Tue Jan 24 10:36:23 2023 -0500

    platform/x86: thinkpad_acpi: Fix profile modes on Intel platforms
    
    commit 1bc5d819f0b9784043ea08570e1b21107aa35739 upstream.
    
    My last commit to fix profile mode displays on AMD platforms caused
    an issue on Intel platforms - sorry!
    
    In it I was reading the current functional mode (MMC, PSC, AMT) from
    the BIOS but didn't account for the fact that on some of our Intel
    platforms I use a different API which returns just the profile and not
    the functional mode.
    
    This commit fixes it so that on Intel platforms it knows the functional
    mode is always MMC.
    
    I also fixed a potential problem that a platform may try to set the mode
    for both MMC and PSC - which was incorrect.
    
    Tested on X1 Carbon 9 (Intel) and Z13 (AMD).
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216963
    Fixes: fde5f74ccfc7 ("platform/x86: thinkpad_acpi: Fix profile mode display in AMT mode")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
    Link: https://lore.kernel.org/r/20230124153623.145188-1-mpearson-lenovo@squebb.ca
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

platform/x86: touchscreen_dmi: Add info for the CSL Panther Tab HD [+ + +]
Author: Michael Klein <m.klein@mvz-labor-lb.de>
Date:   Tue Dec 20 13:11:03 2022 +0100

    platform/x86: touchscreen_dmi: Add info for the CSL Panther Tab HD
    
    [ Upstream commit 36c2b9d6710427f802494ba070621cb415198293 ]
    
    Add touchscreen info for the CSL Panther Tab HD.
    
    Signed-off-by: Michael Klein <m.klein@mvz-labor-lb.de>
    Link: https://lore.kernel.org/r/20221220121103.uiwn5l7fii2iggct@LLGMVZLB-0037
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: AVS: qcom-cpr: Fix an error handling path in cpr_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 17 17:05:41 2022 +0100

    PM: AVS: qcom-cpr: Fix an error handling path in cpr_probe()
    
    [ Upstream commit 6049aae52392539e505bfb8ccbcff3c26f1d2f0b ]
    
    If an error occurs after a successful pm_genpd_init() call, it should be
    undone by a corresponding pm_genpd_remove().
    
    Add the missing call in the error handling path, as already done in the
    remove function.
    
    Fixes: bf6910abf548 ("power: avs: Add support for CPR (Core Power Reduction)")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/0f520597dbad89ab99c217c8986912fa53eaf5f9.1671293108.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ptdma: pt_core_execute_cmd() should use spinlock [+ + +]
Author: Eric Pilmore <epilmore@gigaio.com>
Date:   Wed Jan 18 19:39:08 2023 -0800

    ptdma: pt_core_execute_cmd() should use spinlock
    
    [ Upstream commit 95e5fda3b5f9ed8239b145da3fa01e641cf5d53c ]
    
    The interrupt handler (pt_core_irq_handler()) of the ptdma
    driver can be called from interrupt context. The code flow
    in this function can lead down to pt_core_execute_cmd() which
    will attempt to grab a mutex, which is not appropriate in
    interrupt context and ultimately leads to a kernel panic.
    The fix here changes this mutex to a spinlock, which has
    been verified to resolve the issue.
    
    Fixes: fa5d823b16a9 ("dmaengine: ptdma: Initial driver for the AMD PTDMA")
    Signed-off-by: Eric Pilmore <epilmore@gigaio.com>
    Link: https://lore.kernel.org/r/20230119033907.35071-1-epilmore@gigaio.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8152: add vendor/device ID pair for Microsoft Devkit [+ + +]
Author: Andre Przywara <andre.przywara@arm.com>
Date:   Wed Jan 11 13:32:28 2023 +0000

    r8152: add vendor/device ID pair for Microsoft Devkit
    
    [ Upstream commit be53771c87f4e322a9835d3faa9cd73a4ecdec5b ]
    
    The Microsoft Devkit 2023 is a an ARM64 based machine featuring a
    Realtek 8153 USB3.0-to-GBit Ethernet adapter. As in their other
    machines, Microsoft uses a custom USB device ID.
    
    Add the respective ID values to the driver. This makes Ethernet work on
    the MS Devkit device. The chip has been visually confirmed to be a
    RTL8153.
    
    Signed-off-by: Andre Przywara <andre.przywara@arm.com>
    Link: https://lore.kernel.org/r/20230111133228.190801-1-andre.przywara@arm.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/core: Fix ib block iterator counter overflow [+ + +]
Author: Yonatan Nachum <ynachum@amazon.com>
Date:   Mon Jan 9 13:37:11 2023 +0000

    RDMA/core: Fix ib block iterator counter overflow
    
    [ Upstream commit 0afec5e9cea732cb47014655685a2a47fb180c31 ]
    
    When registering a new DMA MR after selecting the best aligned page size
    for it, we iterate over the given sglist to split each entry to smaller,
    aligned to the selected page size, DMA blocks.
    
    In given circumstances where the sg entry and page size fit certain
    sizes and the sg entry is not aligned to the selected page size, the
    total size of the aligned pages we need to cover the sg entry is >= 4GB.
    Under this circumstances, while iterating page aligned blocks, the
    counter responsible for counting how much we advanced from the start of
    the sg entry is overflowed because its type is u32 and we pass 4GB in
    size. This can lead to an infinite loop inside the iterator function
    because the overflow prevents the counter to be larger
    than the size of the sg entry.
    
    Fix the presented problem by changing the advancement condition to
    eliminate overflow.
    
    Backtrace:
    [  192.374329] efa_reg_user_mr_dmabuf
    [  192.376783] efa_register_mr
    [  192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000
    [  192.386423] pg_sz [0x80000000] umem_length[0xc0000000]
    [  192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3
    [  192.399559] hp_cnt[3], pages_in_hp[524288]
    [  192.403690] umem->sgt_append.sgt.nents[1]
    [  192.407905] number entries: [1], pg_bit: [31]
    [  192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472]
    [  192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472]
    [  192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8]
    [  192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472]
    
    Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks")
    Signed-off-by: Yonatan Nachum <ynachum@amazon.com>
    Link: https://lore.kernel.org/r/20230109133711.13678-1-ynachum@amazon.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rxe: Fix inaccurate constants in rxe_type_info [+ + +]
Author: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
Date:   Tue Dec 20 17:08:47 2022 +0900

    RDMA/rxe: Fix inaccurate constants in rxe_type_info
    
    [ Upstream commit 3a73746b267e5c6a87c9ad26f8c6a48e44da609c ]
    
    ibv_query_device() has reported incorrect device attributes, which are
    actually not used by the device. Make the constants correspond with the
    attributes shown to users.
    
    Fixes: 3ccffe8abf2f ("RDMA/rxe: Move max_elem into rxe_type_info")
    Fixes: 3225717f6dfa ("RDMA/rxe: Replace red-black trees by xarrays")
    Link: https://lore.kernel.org/r/20221220080848.253785-1-matsuda-daisuke@fujitsu.com
    Signed-off-by: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
    Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/rxe: Prevent faulty rkey generation [+ + +]
Author: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
Date:   Tue Dec 20 17:08:48 2022 +0900

    RDMA/rxe: Prevent faulty rkey generation
    
    [ Upstream commit 1aefe5c177c1922119afb4ee443ddd6ac3140b37 ]
    
    If you create MRs more than 0x10000 times after loading the module,
    responder starts to reply NAKs for RDMA/Atomic operations because of rkey
    violation detected in check_rkey(). The root cause is that rkeys are
    incremented each time a new MR is created and the value overflows into the
    range reserved for MWs.
    
    This commit also increases the value of RXE_MAX_MW that has been limited
    unlike other parameters.
    
    Fixes: 0994a1bcd5f7 ("RDMA/rxe: Bump up default maximum values used via uverbs")
    Link: https://lore.kernel.org/r/20221220080848.253785-2-matsuda-daisuke@fujitsu.com
    Signed-off-by: Daisuke Matsuda <matsuda-daisuke@fujitsu.com>
    Tested-by: Li Zhijian <lizhijian@fujitsu.com>
    Reviewed-by: Li Zhijian <lizhijian@fujitsu.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: dt-bindings: samsung,s2mps14: add lost samsung,ext-control-gpios [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Jan 20 14:14:47 2023 +0100

    regulator: dt-bindings: samsung,s2mps14: add lost samsung,ext-control-gpios
    
    commit 4bb3d82a1820c1b609ede8eb2332f3cb038c5840 upstream.
    
    The samsung,ext-control-gpios property was lost during conversion to DT
    schema:
    
      exynos3250-artik5-eval.dtb: pmic@66: regulators:LDO11: Unevaluated properties are not allowed ('samsung,ext-control-gpios' was unexpected)
    
    Fixes: ea98b9eba05c ("regulator: dt-bindings: samsung,s2m: convert to dtschema")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20230120131447.289702-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Oct 29 22:56:36 2022 -0700

    reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST
    
    [ Upstream commit 13678f3feb3009b23aab424864fd0dac0765c83e ]
    
    There is a build error when COMPILE_TEST=y, TI_SCI_PROTOCOL=m,
    and RESET_TI_SCI=y:
    
    drivers/reset/reset-ti-sci.o: in function `ti_sci_reset_probe':
    reset-ti-sci.c:(.text+0x22c): undefined reference to `devm_ti_sci_get_handle'
    
    Fix this by making RESET_TI_SCI honor the Kconfig setting of
    TI_SCI_PROTOCOL when COMPILE_TEST is not set. When COMPILE_TEST is set,
    TI_SCI_PROTOCOL must be disabled (=n).
    
    Fixes: a6af504184c9 ("reset: ti-sci: Allow building under COMPILE_TEST")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: kernel test robot <lkp@intel.com>
    Cc: Nishanth Menon <nm@ti.com>
    Cc: Tero Kristo <kristo@kernel.org>
    Cc: Santosh Shilimkar <ssantosh@kernel.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: Philipp Zabel <p.zabel@pengutronix.de>
    Reviewed-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20221030055636.3139-1-rdunlap@infradead.org
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

reset: uniphier-glue: Fix possible null-ptr-deref [+ + +]
Author: Hui Tang <tanghui20@huawei.com>
Date:   Mon Nov 14 08:49:58 2022 +0800

    reset: uniphier-glue: Fix possible null-ptr-deref
    
    [ Upstream commit 3a2390c6777e3f6662980c6cfc25cafe9e4fef98 ]
    
    It will cause null-ptr-deref when resource_size(res) invoked,
    if platform_get_resource() returns NULL.
    
    Fixes: 499fef09a323 ("reset: uniphier: add USB3 core reset control")
    Signed-off-by: Hui Tang <tanghui20@huawei.com>
    Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Link: https://lore.kernel.org/r/20221114004958.258513-1-tanghui20@huawei.com
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode" [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Fri Dec 16 13:15:34 2022 -0800

    Revert "Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode"
    
    commit 3c44e2b6cde674797b76e76d3a903a63ce8a18bb upstream.
    
    This reverts commit ac5408991ea6b06e29129b4d4861097c4c3e0d59 because
    it causes loss of keyboard on HP 15-da1xxx.
    
    Fixes: ac5408991ea6 ("Input: synaptics - switch touchpad on HP Laptop 15-da3001TU to RMI mode")
    Reported-by: Jiri Slaby <jirislaby@kernel.org>
    Link: https://lore.kernel.org/r/824effa5-8b9a-c28a-82bb-9b0ab24623e1@kernel.org
    Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1206358
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "mm/compaction: fix set skip in fast_find_migrateblock" [+ + +]
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Fri Jan 13 18:33:45 2023 +0100

    Revert "mm/compaction: fix set skip in fast_find_migrateblock"
    
    commit 95e7a450b8190673675836bfef236262ceff084a upstream.
    
    This reverts commit 7efc3b7261030da79001c00d92bc3392fd6c664c.
    
    We have got openSUSE reports (Link 1) for 6.1 kernel with khugepaged
    stalling CPU for long periods of time.  Investigation of tracepoint data
    shows that compaction is stuck in repeating fast_find_migrateblock()
    based migrate page isolation, and then fails to migrate all isolated
    pages.
    
    Commit 7efc3b726103 ("mm/compaction: fix set skip in fast_find_migrateblock")
    was suspected as it was merged in 6.1 and in theory can indeed remove a
    termination condition for fast_find_migrateblock() under certain
    conditions, as it removes a place that always marks a scanned pageblock
    from being re-scanned.  There are other such places, but those can be
    skipped under certain conditions, which seems to match the tracepoint
    data.
    
    Testing of revert also appears to have resolved the issue, thus revert
    the commit until a more robust solution for the original problem is
    developed.
    
    It's also likely this will fix qemu stalls with 6.1 kernel reported in
    Link 2, but that is not yet confirmed.
    
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1206848
    Link: https://lore.kernel.org/kvm/b8017e09-f336-3035-8344-c549086c2340@kernel.org/
    Link: https://lore.kernel.org/lkml/20230125134434.18017-1-mgorman@techsingularity.net/
    Fixes: 7efc3b726103 ("mm/compaction: fix set skip in fast_find_migrateblock")
    Cc: <stable@vger.kernel.org>
    Tested-by: Pedro Falcato <pedro.falcato@gmail.com>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID" [+ + +]
Author: Sasha Levin <sashal@kernel.org>
Date:   Tue Jan 24 07:04:13 2023 -0500

    Revert "selftests/bpf: check null propagation only neither reg is PTR_TO_BTF_ID"
    
    This reverts commit 2e5d5c4ae77dedc7eba0e496474ab93f05b25adf.
    
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv/kprobe: Fix instruction simulation of JALR [+ + +]
Author: Liao Chang <liaochang1@huawei.com>
Date:   Mon Jan 16 14:43:42 2023 +0800

    riscv/kprobe: Fix instruction simulation of JALR
    
    [ Upstream commit ca0254998be4d74cf6add70ccfab0d2dbd362a10 ]
    
    Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following
    crash:
    
    [   32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170
    [   32.093115] Oops [#1]
    [   32.093251] Modules linked in:
    [   32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16
    [   32.093985] Hardware name: riscv-virtio,qemu (DT)
    [   32.094280] epc : ksys_read+0x88/0xd6
    [   32.094855]  ra : ksys_read+0xc0/0xd6
    [   32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0
    [   32.095227]  gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80
    [   32.095500]  t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60
    [   32.095716]  s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708
    [   32.095921]  a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300
    [   32.096171]  a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff
    [   32.096411]  s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170
    [   32.096638]  s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030
    [   32.096865]  s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410
    [   32.097092]  s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c
    [   32.097317]  t5 : ffffffff8000c29c t6 : ffffffff800dbc54
    [   32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d
    [   32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6
    [   32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38
    [   32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2
    
    Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)',
    hence it requires obtaining the target address from rs1 followed by
    updating rd.
    
    Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
    Signed-off-by: Liao Chang <liaochang1@huawei.com>
    Reviewed-by: Guo Ren <guoren@kernel.org>
    Link: https://lore.kernel.org/r/20230116064342.2092136-1-liaochang1@huawei.com
    [Palmer: Pick Guo's cleanup]
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAIT [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Jan 7 01:12:13 2023 +0900

    riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAIT
    
    commit 5b89c6f9b2df2b7cf6da8e0b2b87c8995b378cad upstream.
    
    Since commit 80b6093b55e3 ("kbuild: add -Wundef to KBUILD_CPPFLAGS
    for W=1 builds"), building with W=1 detects misuse of #if.
    
      $ make W=1 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- arch/riscv/kernel/
        [snip]
        AS      arch/riscv/kernel/head.o
      arch/riscv/kernel/head.S:329:5: warning: "CONFIG_RISCV_BOOT_SPINWAIT" is not defined, evaluates to 0 [-Wundef]
        329 | #if CONFIG_RISCV_BOOT_SPINWAIT
            |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
    
    CONFIG_RISCV_BOOT_SPINWAIT is a bool option. #ifdef should be used.
    
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Fixes: 2ffc48fc7071 ("RISC-V: Move spinwait booting method to its own config")
    Link: https://lore.kernel.org/r/20230106161213.2374093-1-masahiroy@kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

riscv: Move call to init_cpu_topology() to later initialization stage [+ + +]
Author: Ley Foon Tan <leyfoon.tan@starfivetech.com>
Date:   Thu Jan 5 11:37:05 2023 +0800

    riscv: Move call to init_cpu_topology() to later initialization stage
    
    [ Upstream commit c1d6105869464635d8a2bcf87a43c05f4c0cfca4 ]
    
    If "capacity-dmips-mhz" is present in a CPU DT node,
    topology_parse_cpu_capacity() will fail to allocate memory.  arm64, with
    which this code path is shared, does not call
    topology_parse_cpu_capacity() until later in boot where memory
    allocation is available.  While "capacity-dmips-mhz" is not yet a valid
    property on RISC-V, invalid properties should be ignored rather than
    cause issues.  Move init_cpu_topology(), which calls
    topology_parse_cpu_capacity(), to a later initialization stage, to match
    arm64.
    
    As a side effect of this change, RISC-V is "protected" from changes to
    core topology code that would work on arm64 where memory allocation is
    safe but on RISC-V isn't.
    
    Fixes: 03f11f03dbfe ("RISC-V: Parse cpu topology during boot.")
    Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Signed-off-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
    Link: https://lore.kernel.org/r/20230105033705.3946130-1-leyfoon.tan@starfivetech.com
    [Palmer: use Conor's commit text]
    Link: https://lore.kernel.org/linux-riscv/20230104183033.755668-1-pierre.gondois@arm.com/T/#me592d4c8b9508642954839f0077288a353b0b9b2
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/debug: add _ASM_S390_ prefix to header guard [+ + +]
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Jan 3 15:11:07 2023 +0100

    s390/debug: add _ASM_S390_ prefix to header guard
    
    [ Upstream commit 0d4d52361b6c29bf771acd4fa461f06d78fb2fac ]
    
    Using DEBUG_H without a prefix is very generic and inconsistent with
    other header guards in arch/s390/include/asm. In fact it collides with
    the same name in the ath9k wireless driver though that depends on !S390
    via disabled wireless support. Let's just use a consistent header guard
    name and prevent possible future trouble.
    
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390: expicitly align _edata and _end symbols on page boundary [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Wed Dec 7 17:15:19 2022 +0100

    s390: expicitly align _edata and _end symbols on page boundary
    
    [ Upstream commit 45d619bdaf799196d702a9ae464b07066d6db2f9 ]
    
    Symbols _edata and _end in the linker script are the
    only unaligned expicitly on page boundary. Although
    _end is aligned implicitly by BSS_SECTION macro that
    is still inconsistent and could lead to a bug if a tool
    or function would assume that _edata is as aligned as
    others.
    
    For example, vmem_map_init() function does not align
    symbols _etext, _einittext etc. Should these symbols
    be unaligned as well, the size of ranges to update
    were short on one page.
    
    Instead of fixing every occurrence of this kind in the
    code and external tools just force the alignment on
    these two symbols.
    
    Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Thu Jan 12 16:55:29 2023 -0800

    sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb
    
    [ Upstream commit a22b7388d658ecfcd226600c8c34ce4481e88655 ]
    
    Peek at old qdisc and graft only when deleting a leaf class in the htb,
    rather than when deleting the htb itself. Do not peek at the qdisc of the
    netdev queue when destroying the htb. The caller may already have grafted a
    new qdisc that is not part of the htb structure being destroyed.
    
    This fix resolves two use cases.
    
      1. Using tc to destroy the htb.
        - Netdev was being prematurely activated before the htb was fully
          destroyed.
      2. Using tc to replace the htb with another qdisc (which also leads to
         the htb being destroyed).
        - Premature netdev activation like previous case. Newly grafted qdisc
          was also getting accidentally overwritten when destroying the htb.
    
    Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Maxim Mikityanskiy <maxtram95@gmail.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20230113005528.302625-1-rrameshbabu@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/fair: Check if prev_cpu has highest spare cap in feec() [+ + +]
Author: Pierre Gondois <pierre.gondois@arm.com>
Date:   Thu Oct 6 10:10:52 2022 +0200

    sched/fair: Check if prev_cpu has highest spare cap in feec()
    
    [ Upstream commit ad841e569f5c88e3332b32a000f251f33ff32187 ]
    
    When evaluating the CPU candidates in the perf domain (pd) containing
    the previously used CPU (prev_cpu), find_energy_efficient_cpu()
    evaluates the energy of the pd:
    - without the task (base_energy)
    - with the task placed on prev_cpu (if the task fits)
    - with the task placed on the CPU with the highest spare capacity,
      prev_cpu being excluded from this set
    
    If prev_cpu is already the CPU with the highest spare capacity,
    max_spare_cap_cpu will be the CPU with the second highest spare
    capacity.
    
    On an Arm64 Juno-r2, with a workload of 10 tasks at a 10% duty cycle,
    when prev_cpu and max_spare_cap_cpu are both valid candidates,
    prev_spare_cap > max_spare_cap at ~82%.
    Thus the energy of the pd when placing the task on max_spare_cap_cpu
    is computed with no possible positive outcome 82% most of the time.
    
    Do not consider max_spare_cap_cpu as a valid candidate if
    prev_spare_cap > max_spare_cap.
    
    Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20221006081052.3862167-2-pierre.gondois@arm.com
    Stable-dep-of: e26fd28db828 ("sched/uclamp: Fix a uninitialized variable warnings")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sched/uclamp: Fix a uninitialized variable warnings [+ + +]
Author: Qais Yousef <qyousef@layalina.io>
Date:   Thu Jan 12 12:27:07 2023 +0000

    sched/uclamp: Fix a uninitialized variable warnings
    
    [ Upstream commit e26fd28db82899be71b4b949527373d0a6be1e65 ]
    
    Addresses the following warnings:
    
    > config: riscv-randconfig-m031-20221111
    > compiler: riscv64-linux-gcc (GCC) 12.1.0
    >
    > smatch warnings:
    > kernel/sched/fair.c:7263 find_energy_efficient_cpu() error: uninitialized symbol 'util_min'.
    > kernel/sched/fair.c:7263 find_energy_efficient_cpu() error: uninitialized symbol 'util_max'.
    
    Fixes: 244226035a1f ("sched/uclamp: Fix fits_capacity() check in feec()")
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
    Link: https://lore.kernel.org/r/20230112122708.330667-2-qyousef@layalina.io
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: hisi_sas: Set a port invalid only if there are no devices attached when refreshing port id [+ + +]
Author: Yihang Li <liyihang9@huawei.com>
Date:   Wed Jan 4 12:03:20 2023 +0800

    scsi: hisi_sas: Set a port invalid only if there are no devices attached when refreshing port id
    
    [ Upstream commit f58c89700630da6554b24fd3df293a24874c10c1 ]
    
    Currently the driver sets the port invalid if one phy in the port is not
    enabled, which may cause issues in expander situation. In directly attached
    situation, if phy up doesn't occur in time when refreshing port id, the
    port is incorrectly set to invalid which will also cause disk lost.
    
    Therefore set a port invalid only if there are no devices attached to the
    port.
    
    Signed-off-by: Yihang Li <liyihang9@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1672805000-141102-3-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hisi_sas: Use abort task set to reset SAS disks when discovered [+ + +]
Author: Xingui Yang <yangxingui@huawei.com>
Date:   Wed Jan 4 12:03:19 2023 +0800

    scsi: hisi_sas: Use abort task set to reset SAS disks when discovered
    
    [ Upstream commit 037b48057e8b485a8d72f808122796aeadbbee32 ]
    
    Currently clear task set is used to abort all commands remaining in the
    disk when the SAS disk is discovered, and if the disk is discovered by two
    initiators, other I_T nexuses are also affected. So use abort task set
    instead and take effect only on the specified I_T nexus.
    
    Signed-off-by: Xingui Yang <yangxingui@huawei.com>
    Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
    Link: https://lore.kernel.org/r/1672805000-141102-2-git-send-email-chenxiang66@hisilicon.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix allocation size for scsi_host_alloc() [+ + +]
Author: Alexey V. Vissarionov <gremlin@altlinux.org>
Date:   Wed Jan 18 06:12:55 2023 +0300

    scsi: hpsa: Fix allocation size for scsi_host_alloc()
    
    [ Upstream commit bbbd25499100c810ceaf5193c3cfcab9f7402a33 ]
    
    The 'h' is a pointer to struct ctlr_info, so it's just 4 or 8 bytes, while
    the structure itself is much bigger.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: edd163687ea5 ("hpsa: add driver for HP Smart Array controllers.")
    Link: https://lore.kernel.org/r/20230118031255.GE15213@altlinux.org
    Signed-off-by: Alexey V. Vissarionov <gremlin@altlinux.org>
    Acked-by: Don Brace <don.brace@microchip.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: iscsi: Fix multiple iSCSI session unbind events sent to userspace [+ + +]
Author: Wenchao Hao <haowenchao@huawei.com>
Date:   Sat Nov 26 09:07:52 2022 +0800

    scsi: iscsi: Fix multiple iSCSI session unbind events sent to userspace
    
    [ Upstream commit a3be19b91ea7121d388084e8c07f5b1b982eb40c ]
    
    It was observed that the kernel would potentially send
    ISCSI_KEVENT_UNBIND_SESSION multiple times. Introduce 'target_state' in
    iscsi_cls_session() to make sure session will send only one unbind session
    event.
    
    This introduces a regression wrt. the issue fixed in commit 13e60d3ba287
    ("scsi: iscsi: Report unbind session event when the target has been
    removed"). If iscsid dies for any reason after sending an unbind session to
    kernel, once iscsid is restarted, the kernel's ISCSI_KEVENT_UNBIND_SESSION
    event is lost and userspace is then unable to logout. However, the session
    is actually in invalid state (its target_id is INVALID) so iscsid should
    not sync this session during restart.
    
    Consequently we need to check the session's target state during iscsid
    restart.  If session is in unbound state, do not sync this session and
    perform session teardown. This is OK because once a session is unbound, we
    can not recover it any more (mainly because its target id is INVALID).
    
    Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
    Link: https://lore.kernel.org/r/20221126010752.231917-1-haowenchao@huawei.com
    Reviewed-by: Mike Christie <michael.christie@oracle.com>
    Reviewed-by: Wu Bo <wubo40@huawei.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ufs: core: Fix devfreq deadlocks [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Jan 16 17:12:01 2023 +0100

    scsi: ufs: core: Fix devfreq deadlocks
    
    commit ba81043753fffbc2ad6e0c5ff2659f12ac2f46b4 upstream.
    
    There is a lock inversion and rwsem read-lock recursion in the devfreq
    target callback which can lead to deadlocks.
    
    Specifically, ufshcd_devfreq_scale() already holds a clk_scaling_lock
    read lock when toggling the write booster, which involves taking the
    dev_cmd mutex before taking another clk_scaling_lock read lock.
    
    This can lead to a deadlock if another thread:
    
      1) tries to acquire the dev_cmd and clk_scaling locks in the correct
         order, or
    
      2) takes a clk_scaling write lock before the attempt to take the
         clk_scaling read lock a second time.
    
    Fix this by dropping the clk_scaling_lock before toggling the write booster
    as was done before commit 0e9d4ca43ba8 ("scsi: ufs: Protect some contexts
    from unexpected clock scaling").
    
    While the devfreq callbacks are already serialised, add a second
    serialising mutex to handle the unlikely case where a callback triggered
    through the devfreq sysfs interface is racing with a request to disable
    clock scaling through the UFS controller 'clkscale_enable' sysfs
    attribute. This could otherwise lead to the write booster being left
    disabled after having disabled clock scaling.
    
    Also take the new mutex in ufshcd_clk_scaling_allow() to make sure that any
    pending write booster update has completed on return.
    
    Note that this currently only affects Qualcomm platforms since commit
    87bd05016a64 ("scsi: ufs: core: Allow host driver to disable wb toggling
    during clock scaling").
    
    The lock inversion (i.e. 1 above) was reported by lockdep as:
    
     ======================================================
     WARNING: possible circular locking dependency detected
     6.1.0-next-20221216 #211 Not tainted
     ------------------------------------------------------
     kworker/u16:2/71 is trying to acquire lock:
     ffff076280ba98a0 (&hba->dev_cmd.lock){+.+.}-{3:3}, at: ufshcd_query_flag+0x50/0x1c0
    
     but task is already holding lock:
     ffff076280ba9cf0 (&hba->clk_scaling_lock){++++}-{3:3}, at: ufshcd_devfreq_scale+0x2b8/0x380
    
     which lock already depends on the new lock.
    [  +0.011606]
     the existing dependency chain (in reverse order) is:
    
     -> #1 (&hba->clk_scaling_lock){++++}-{3:3}:
            lock_acquire+0x68/0x90
            down_read+0x58/0x80
            ufshcd_exec_dev_cmd+0x70/0x2c0
            ufshcd_verify_dev_init+0x68/0x170
            ufshcd_probe_hba+0x398/0x1180
            ufshcd_async_scan+0x30/0x320
            async_run_entry_fn+0x34/0x150
            process_one_work+0x288/0x6c0
            worker_thread+0x74/0x450
            kthread+0x118/0x120
            ret_from_fork+0x10/0x20
    
     -> #0 (&hba->dev_cmd.lock){+.+.}-{3:3}:
            __lock_acquire+0x12a0/0x2240
            lock_acquire.part.0+0xcc/0x220
            lock_acquire+0x68/0x90
            __mutex_lock+0x98/0x430
            mutex_lock_nested+0x2c/0x40
            ufshcd_query_flag+0x50/0x1c0
            ufshcd_query_flag_retry+0x64/0x100
            ufshcd_wb_toggle+0x5c/0x120
            ufshcd_devfreq_scale+0x2c4/0x380
            ufshcd_devfreq_target+0xf4/0x230
            devfreq_set_target+0x84/0x2f0
            devfreq_update_target+0xc4/0xf0
            devfreq_monitor+0x38/0x1f0
            process_one_work+0x288/0x6c0
            worker_thread+0x74/0x450
            kthread+0x118/0x120
            ret_from_fork+0x10/0x20
    
     other info that might help us debug this:
      Possible unsafe locking scenario:
            CPU0                    CPU1
            ----                    ----
       lock(&hba->clk_scaling_lock);
                                    lock(&hba->dev_cmd.lock);
                                    lock(&hba->clk_scaling_lock);
       lock(&hba->dev_cmd.lock);
    
      *** DEADLOCK ***
    
    Fixes: 0e9d4ca43ba8 ("scsi: ufs: Protect some contexts from unexpected clock scaling")
    Cc: stable@vger.kernel.org      # 5.12
    Cc: Can Guo <quic_cang@quicinc.com>
    Tested-by: Andrew Halaney <ahalaney@redhat.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20230116161201.16923-1-johan+linaro@kernel.org
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sctp: fail if no bound addresses can be used for a given scope [+ + +]
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Jan 23 14:59:33 2023 -0300

    sctp: fail if no bound addresses can be used for a given scope
    
    [ Upstream commit 458e279f861d3f61796894cd158b780765a1569f ]
    
    Currently, if you bind the socket to something like:
            servaddr.sin6_family = AF_INET6;
            servaddr.sin6_port = htons(0);
            servaddr.sin6_scope_id = 0;
            inet_pton(AF_INET6, "::1", &servaddr.sin6_addr);
    
    And then request a connect to:
            connaddr.sin6_family = AF_INET6;
            connaddr.sin6_port = htons(20000);
            connaddr.sin6_scope_id = if_nametoindex("lo");
            inet_pton(AF_INET6, "fe88::1", &connaddr.sin6_addr);
    
    What the stack does is:
     - bind the socket
     - create a new asoc
     - to handle the connect
       - copy the addresses that can be used for the given scope
       - try to connect
    
    But the copy returns 0 addresses, and the effect is that it ends up
    trying to connect as if the socket wasn't bound, which is not the
    desired behavior. This unexpected behavior also allows KASLR leaks
    through SCTP diag interface.
    
    The fix here then is, if when trying to copy the addresses that can
    be used for the scope used in connect() it returns 0 addresses, bail
    out. This is what TCP does with a similar reproducer.
    
    Reported-by: Pietro Borrello <borrello@diag.uniroma1.it>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/9fcd182f1099f86c6661f3717f63712ddd1c676c.1674496737.git.marcelo.leitner@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/net: toeplitz: fix race on tpacket_v3 block close [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Jan 18 10:18:47 2023 -0500

    selftests/net: toeplitz: fix race on tpacket_v3 block close
    
    [ Upstream commit 903848249a781d76d59561d51676c95b3a4d7162 ]
    
    Avoid race between process wakeup and tpacket_v3 block timeout.
    
    The test waits for cfg_timeout_msec for packets to arrive. Packets
    arrive in tpacket_v3 rings, which pass packets ("frames") to the
    process in batches ("blocks"). The sk waits for req3.tp_retire_blk_tov
    msec to release a block.
    
    Set the block timeout lower than the process waiting time, else
    the process may find that no block has been released by the time it
    scans the socket list. Convert to a ring of more than one, smaller,
    blocks with shorter timeouts. Blocks must be page aligned, so >= 64KB.
    
    Fixes: 5ebfb4cc3048 ("selftests/net: toeplitz test")
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20230118151847.4124260-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: imx8m: Fix incorrect check for of_clk_get_by_name() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sat Dec 31 13:58:48 2022 +0400

    soc: imx8m: Fix incorrect check for of_clk_get_by_name()
    
    [ Upstream commit 490748874ebf1875420fc29b335bba2075dd1b5e ]
    
    of_clk_get_by_name() returns error pointers instead of NULL.
    Use IS_ERR() checks the return value to catch errors.
    
    Fixes: 836fb30949d9 ("soc: imx8m: Enable OCOTP clock before reading the register")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: imx: imx8mp-blk-ctrl: don't set power device name [+ + +]
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Fri Aug 26 21:13:03 2022 +0200

    soc: imx: imx8mp-blk-ctrl: don't set power device name
    
    [ Upstream commit 21b84ebeee79d91e405f87f051e9489ef30ecad6 ]
    
    Setting the device name after it has been registered confuses the sysfs
    cleanup paths. This has already been fixed for the imx8m-blk-ctrl driver in
    b64b46fbaa1d ("Revert "soc: imx: imx8m-blk-ctrl: set power device name""),
    but the same problem exists in imx8mp-blk-ctrl.
    
    Fixes: 556f5cf9568a ("soc: imx: add i.MX8MP HSIO blk-ctrl")
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Reviewed-by: Peng Fan <peng.fan@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: imx: imx8mp-blk-ctrl: enable global pixclk with HDMI_TX_PHY PD [+ + +]
Author: Lucas Stach <l.stach@pengutronix.de>
Date:   Sat Dec 31 13:40:25 2022 +0800

    soc: imx: imx8mp-blk-ctrl: enable global pixclk with HDMI_TX_PHY PD
    
    [ Upstream commit b814eda949c324791580003303aa608761cfde3f ]
    
    NXP internal information shows that the PHY refclk is gated by the
    GLOBAL_TX_PIX_CLK_EN bit, so to allow the PHY PLL to lock without the
    LCDIF being already active, tie this bit to the HDMI_TX_PHY power
    domain.
    
    Fixes: e3442022f543 ("soc: imx: add i.MX8MP HDMI blk-ctrl")
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: cadence: Fix busy cycles calculation [+ + +]
Author: Witold Sadowski <wsadowski@marvell.com>
Date:   Mon Dec 19 06:42:48 2022 -0800

    spi: cadence: Fix busy cycles calculation
    
    [ Upstream commit e8bb8f19e73a1e855e54788f8673b9b49e46b5cd ]
    
    If xSPI is in x2/x4/x8 mode to calculate busy
    cycles, busy bits count must be divided by the number
    of lanes.
    If opcommand is using 8 busy bits, but SPI is
    in x4 mode, there will be only 2 busy cycles.
    
    Signed-off-by: Witold Sadowski <wsadowski@marvell.com>
    Reviewed-by: Chandrakala Chavva <cchavva@marvell.com>
    Reviewed-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
    Link: https://lore.kernel.org/r/20221219144254.20883-2-wsadowski@marvell.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: spidev: remove debug messages that access spidev->spi without locking [+ + +]
Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Date:   Fri Jan 6 11:07:19 2023 +0100

    spi: spidev: remove debug messages that access spidev->spi without locking
    
    [ Upstream commit 6b35b173dbc1711f8d272e3f322d2ad697015919 ]
    
    The two debug messages in spidev_open() dereference spidev->spi without
    taking the lock and without checking if it's not null. This can lead to
    a crash. Drop the messages as they're not needed - the user-space will
    get informed about ENOMEM with the syscall return value.
    
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Link: https://lore.kernel.org/r/20230106100719.196243-2-brgl@bgdev.pl
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: avoid the lookup process failing to get sk in ehash table [+ + +]
Author: Jason Xing <kernelxing@tencent.com>
Date:   Wed Jan 18 09:59:41 2023 +0800

    tcp: avoid the lookup process failing to get sk in ehash table
    
    [ Upstream commit 3f4ca5fafc08881d7a57daa20449d171f2887043 ]
    
    While one cpu is working on looking up the right socket from ehash
    table, another cpu is done deleting the request socket and is about
    to add (or is adding) the big socket from the table. It means that
    we could miss both of them, even though it has little chance.
    
    Let me draw a call trace map of the server side.
       CPU 0                           CPU 1
       -----                           -----
    tcp_v4_rcv()                  syn_recv_sock()
                                inet_ehash_insert()
                                -> sk_nulls_del_node_init_rcu(osk)
    __inet_lookup_established()
                                -> __sk_nulls_add_node_rcu(sk, list)
    
    Notice that the CPU 0 is receiving the data after the final ack
    during 3-way shakehands and CPU 1 is still handling the final ack.
    
    Why could this be a real problem?
    This case is happening only when the final ack and the first data
    receiving by different CPUs. Then the server receiving data with
    ACK flag tries to search one proper established socket from ehash
    table, but apparently it fails as my map shows above. After that,
    the server fetches a listener socket and then sends a RST because
    it finds a ACK flag in the skb (data), which obeys RST definition
    in RFC 793.
    
    Besides, Eric pointed out there's one more race condition where it
    handles tw socket hashdance. Only by adding to the tail of the list
    before deleting the old one can we avoid the race if the reader has
    already begun the bucket traversal and it would possibly miss the head.
    
    Many thanks to Eric for great help from beginning to end.
    
    Fixes: 5e0724d027f0 ("tcp/dccp: fix hashdance race for passive sessions")
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Jason Xing <kernelxing@tencent.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Link: https://lore.kernel.org/lkml/20230112065336.41034-1-kerneljasonxing@gmail.com/
    Link: https://lore.kernel.org/r/20230118015941.1313-1-kerneljasonxing@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp: fix rate_app_limited to default to 1 [+ + +]
Author: David Morley <morleyd@google.com>
Date:   Thu Jan 19 19:00:28 2023 +0000

    tcp: fix rate_app_limited to default to 1
    
    [ Upstream commit 300b655db1b5152d6101bcb6801d50899b20c2d6 ]
    
    The initial default value of 0 for tp->rate_app_limited was incorrect,
    since a flow is indeed application-limited until it first sends
    data. Fixing the default to be 1 is generally correct but also
    specifically will help user-space applications avoid using the initial
    tcpi_delivery_rate value of 0 that persists until the connection has
    some non-zero bandwidth sample.
    
    Fixes: eb8329e0a04d ("tcp: export data delivery rate")
    Suggested-by: Yuchung Cheng <ycheng@google.com>
    Signed-off-by: David Morley <morleyd@google.com>
    Signed-off-by: Neal Cardwell <ncardwell@google.com>
    Tested-by: David Morley <morleyd@google.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal/core: fix error code in __thermal_cooling_device_register() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Fri Oct 28 18:02:34 2022 +0300

    thermal/core: fix error code in __thermal_cooling_device_register()
    
    [ Upstream commit e49a1e1ee078aee21006192076a8d93335e0daa9 ]
    
    Return an error pointer if ->get_max_state() fails.  The current code
    returns NULL which will cause an oops in the callers.
    
    Fixes: c408b3d1d9bb ("thermal: Validate new state in cur_state_store()")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 6c54b7bc8a31 ("thermal: core: call put_device() only after device_register() fails")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal: core: call put_device() only after device_register() fails [+ + +]
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Wed Jan 18 14:08:24 2023 +0530

    thermal: core: call put_device() only after device_register() fails
    
    [ Upstream commit 6c54b7bc8a31ce0f7cc7f8deef05067df414f1d8 ]
    
    put_device() shouldn't be called before a prior call to
    device_register(). __thermal_cooling_device_register() doesn't follow
    that properly and needs fixing. Also
    thermal_cooling_device_destroy_sysfs() is getting called unnecessarily
    on few error paths.
    
    Fix all this by placing the calls at the right place.
    
    Based on initial work done by Caleb Connolly.
    
    Fixes: 4748f9687caa ("thermal: core: fix some possible name leaks in error paths")
    Fixes: c408b3d1d9bb ("thermal: Validate new state in cur_state_store()")
    Reported-by: Caleb Connolly <caleb.connolly@linaro.org>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Tested-by: Frank Rowand <frowand.list@gmail.com>
    Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
    Tested-by: Caleb Connolly <caleb.connolly@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Jan 25 13:17:42 2023 +0100

    thermal: intel: int340x: Add locking to int340x_thermal_get_trip_type()
    
    [ Upstream commit acd7e9ee57c880b99671dd99680cb707b7b5b0ee ]
    
    In order to prevent int340x_thermal_get_trip_type() from possibly
    racing with int340x_thermal_read_trips() invoked by int3403_notify()
    add locking to it in analogy with int340x_thermal_get_trip_temp().
    
    Fixes: 6757a7abe47b ("thermal: intel: int340x: Protect trip temperature from concurrent updates")
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

thermal: intel: int340x: Protect trip temperature from concurrent updates [+ + +]
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Mon Jan 23 09:21:10 2023 -0800

    thermal: intel: int340x: Protect trip temperature from concurrent updates
    
    commit 6757a7abe47bcb12cb2d45661067e182424b0ee3 upstream.
    
    Trip temperatures are read using ACPI methods and stored in the memory
    during zone initializtion and when the firmware sends a notification for
    change. This trip temperature is returned when the thermal core calls via
    callback get_trip_temp().
    
    But it is possible that while updating the memory copy of the trips when
    the firmware sends a notification for change, thermal core is reading the
    trip temperature via the callback get_trip_temp(). This may return invalid
    trip temperature.
    
    To address this add a mutex to protect the invalid temperature reads in
    the callback get_trip_temp() and int340x_thermal_read_trips().
    
    Fixes: 5fbf7f27fa3d ("Thermal/int340x: Add common thermal zone handler")
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Cc: 5.0+ <stable@vger.kernel.org> # 5.0+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

thermal: Validate new state in cur_state_store() [+ + +]
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date:   Mon Oct 17 15:33:01 2022 +0530

    thermal: Validate new state in cur_state_store()
    
    [ Upstream commit c408b3d1d9bbc7de5fb0304fea424ef2539da616 ]
    
    In cur_state_store(), the new state of the cooling device is received
    from user-space and is not validated by the thermal core but the same is
    left for the individual drivers to take care of. Apart from duplicating
    the code it leaves possibility for introducing bugs where a driver may
    not do it right.
    
    Lets make the thermal core check the new state itself and store the max
    value in the cooling device structure.
    
    Link: https://lore.kernel.org/all/Y0ltRJRjO7AkawvE@kili/
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 6c54b7bc8a31 ("thermal: core: call put_device() only after device_register() fails")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tomoyo: fix broken dependency on *.conf.default [+ + +]
Author: Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat Jan 7 16:47:41 2023 +0900

    tomoyo: fix broken dependency on *.conf.default
    
    [ Upstream commit eaf2213ba563b2d74a1f2c13a6b258273f689802 ]
    
    If *.conf.default is updated, builtin-policy.h should be rebuilt,
    but this does not work when compiled with O= option.
    
    [Without this commit]
    
      $ touch security/tomoyo/policy/exception_policy.conf.default
      $ make O=/tmp security/tomoyo/
      make[1]: Entering directory '/tmp'
        GEN     Makefile
        CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
        DESCEND objtool
      make[1]: Leaving directory '/tmp'
    
    [With this commit]
    
      $ touch security/tomoyo/policy/exception_policy.conf.default
      $ make O=/tmp security/tomoyo/
      make[1]: Entering directory '/tmp'
        GEN     Makefile
        CALL    /home/masahiro/ref/linux/scripts/checksyscalls.sh
        DESCEND objtool
        POLICY  security/tomoyo/builtin-policy.h
        CC      security/tomoyo/common.o
        AR      security/tomoyo/built-in.a
      make[1]: Leaving directory '/tmp'
    
    $(srctree)/ is essential because $(wildcard ) does not follow VPATH.
    
    Fixes: f02dee2d148b ("tomoyo: Do not generate empty policy files")
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/nolibc: fix missing includes causing build issues at -O0 [+ + +]
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon Jan 9 08:54:40 2023 +0100

    tools/nolibc: fix missing includes causing build issues at -O0
    
    [ Upstream commit 55abdd1f5e1e07418bf4a46c233a92f83cb5ae97 ]
    
    After the nolibc includes were split to facilitate portability from
    standard libcs, programs that include only what they need may miss
    some symbols which are needed by libgcc. This is the case for raise()
    which is needed by the divide by zero code in some architectures for
    example.
    
    Regardless, being able to include only the apparently needed files is
    convenient.
    
    Instead of trying to move all exported definitions to a single file,
    since this can change over time, this patch takes another approach
    consisting in including the nolibc header at the end of all standard
    include files. This way their types and functions are already known
    at the moment of inclusion, and including any single one of them is
    sufficient to bring all the required ones.
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools/nolibc: Fix S_ISxxx macros [+ + +]
Author: Warner Losh <imp@bsdimp.com>
Date:   Mon Jan 9 08:54:38 2023 +0100

    tools/nolibc: Fix S_ISxxx macros
    
    [ Upstream commit 16f5cea74179b5795af7ce359971f5128d10f80e ]
    
    The mode field has the type encoded as an value in a field, not as a bit
    mask. Mask the mode with S_IFMT instead of each type to test. Otherwise,
    false positives are possible: eg S_ISDIR will return true for block
    devices because S_IFDIR = 0040000 and S_IFBLK = 0060000 since mode is
    masked with S_IFDIR instead of S_IFMT. These macros now match the
    similar definitions in tools/include/uapi/linux/stat.h.
    
    Signed-off-by: Warner Losh <imp@bsdimp.com>
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tools/nolibc: prevent gcc from making memset() loop over itself [+ + +]
Author: Willy Tarreau <w@1wt.eu>
Date:   Mon Jan 9 08:54:41 2023 +0100

    tools/nolibc: prevent gcc from making memset() loop over itself
    
    [ Upstream commit 1bfbe1f3e96720daf185f03d101f072d69753f88 ]
    
    When building on ARM in thumb mode with gcc-11.3 at -O2 or -O3,
    nolibc-test segfaults during the select() tests. It turns out that at
    this level, gcc recognizes an opportunity for using memset() to zero
    the fd_set, but it miscompiles it because it also recognizes a memset
    pattern as well, and decides to call memset() from the memset() code:
    
      000122bc <memset>:
         122bc:       b510            push    {r4, lr}
         122be:       0004            movs    r4, r0
         122c0:       2a00            cmp     r2, #0
         122c2:       d003            beq.n   122cc <memset+0x10>
         122c4:       23ff            movs    r3, #255        ; 0xff
         122c6:       4019            ands    r1, r3
         122c8:       f7ff fff8       bl      122bc <memset>
         122cc:       0020            movs    r0, r4
         122ce:       bd10            pop     {r4, pc}
    
    Simply placing an empty asm() statement inside the loop suffices to
    avoid this.
    
    Signed-off-by: Willy Tarreau <w@1wt.eu>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: gpio: fix -c option of gpio-event-mon [+ + +]
Author: Ivo Borisov Shopov <ivoshopov@gmail.com>
Date:   Thu Jan 26 15:10:33 2023 +0200

    tools: gpio: fix -c option of gpio-event-mon
    
    [ Upstream commit 677d85e1a1ee69fa05ccea83847309484be3781c ]
    
    Following line should listen for a rising edge and exit after the first
    one since '-c 1' is provided.
    
        # gpio-event-mon -n gpiochip1 -o 0 -r -c 1
    
    It works with kernel 4.19 but it doesn't work with 5.10. In 5.10 the
    above command doesn't exit after the first rising edge it keep listening
    for an event forever. The '-c 1' is not taken into an account.
    The problem is in commit 62757c32d5db ("tools: gpio: add multi-line
    monitoring to gpio-event-mon").
    Before this commit the iterator 'i' in monitor_device() is used for
    counting of the events (loops). In the case of the above command (-c 1)
    we should start from 0 and increment 'i' only ones and hit the 'break'
    statement and exit the process. But after the above commit counting
    doesn't start from 0, it start from 1 when we listen on one line.
    It is because 'i' is used from one more purpose, counting of lines
    (num_lines) and it isn't restore to 0 after following code
    
        for (i = 0; i < num_lines; i++)
            gpiotools_set_bit(&values.mask, i);
    
    Restore the initial value of the iterator to 0 in order to allow counting
    of loops to work for any cases.
    
    Fixes: 62757c32d5db ("tools: gpio: add multi-line monitoring to gpio-event-mon")
    Signed-off-by: Ivo Borisov Shopov <ivoshopov@gmail.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    [Bartosz: tweak the commit message]
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
trace_events_hist: add check for return value of 'create_hist_field' [+ + +]
Author: Natalia Petrova <n.petrova@fintech.ru>
Date:   Wed Jan 11 15:04:09 2023 +0300

    trace_events_hist: add check for return value of 'create_hist_field'
    
    commit 8b152e9150d07a885f95e1fd401fc81af202d9a4 upstream.
    
    Function 'create_hist_field' is called recursively at
    trace_events_hist.c:1954 and can return NULL-value that's why we have
    to check it to avoid null pointer dereference.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lkml.kernel.org/r/20230111120409.4111-1-n.petrova@fintech.ru
    
    Cc: stable@vger.kernel.org
    Fixes: 30350d65ac56 ("tracing: Add variable support to hist triggers")
    Signed-off-by: Natalia Petrova <n.petrova@fintech.ru>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/osnoise: Use built-in RCU list checking [+ + +]
Author: Chuang Wang <nashuiliang@gmail.com>
Date:   Tue Dec 27 10:30:36 2022 +0800

    tracing/osnoise: Use built-in RCU list checking
    
    [ Upstream commit 685b64e4d6da4be8b4595654a57db663b3d1dfc2 ]
    
    list_for_each_entry_rcu() has built-in RCU and lock checking.
    
    Pass cond argument to list_for_each_entry_rcu() to silence false lockdep
    warning when CONFIG_PROVE_RCU_LIST is enabled.
    
    Execute as follow:
    
     [tracing]# echo osnoise > current_tracer
     [tracing]# echo 1 > tracing_on
     [tracing]# echo 0 > tracing_on
    
    The trace_types_lock is held when osnoise_tracer_stop() or
    timerlat_tracer_stop() are called in the non-RCU read side section.
    So, pass lockdep_is_held(&trace_types_lock) to silence false lockdep
    warning.
    
    Link: https://lkml.kernel.org/r/20221227023036.784337-1-nashuiliang@gmail.com
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: dae181349f1e ("tracing/osnoise: Support a list of trace_array *tr")
    Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org>
    Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracing: Make sure trace_printk() can output as soon as it can be used [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Jan 4 16:14:12 2023 -0500

    tracing: Make sure trace_printk() can output as soon as it can be used
    
    commit 3bb06eb6e9acf7c4a3e1b5bc87aed398ff8e2253 upstream.
    
    Currently trace_printk() can be used as soon as early_trace_init() is
    called from start_kernel(). But if a crash happens, and
    "ftrace_dump_on_oops" is set on the kernel command line, all you get will
    be:
    
      [    0.456075]   <idle>-0         0dN.2. 347519us : Unknown type 6
      [    0.456075]   <idle>-0         0dN.2. 353141us : Unknown type 6
      [    0.456075]   <idle>-0         0dN.2. 358684us : Unknown type 6
    
    This is because the trace_printk() event (type 6) hasn't been registered
    yet. That gets done via an early_initcall(), which may be early, but not
    early enough.
    
    Instead of registering the trace_printk() event (and other ftrace events,
    which are not trace events) via an early_initcall(), have them registered at
    the same time that trace_printk() can be used. This way, if there is a
    crash before early_initcall(), then the trace_printk()s will actually be
    useful.
    
    Link: https://lkml.kernel.org/r/20230104161412.019f6c55@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Fixes: e725c731e3bb1 ("tracing: Split tracing initialization into two for early initialization")
    Reported-by: "Joel Fernandes (Google)" <joel@joelfernandes.org>
    Tested-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
treewide: fix up files incorrectly marked executable [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 26 10:05:39 2023 -0800

    treewide: fix up files incorrectly marked executable
    
    [ Upstream commit 262b42e02d1e0b5ad1b33e9b9842e178c16231de ]
    
    I'm not exactly clear on what strange workflow causes people to do it,
    but clearly occasionally some files end up being committed as executable
    even though they clearly aren't.
    
    This is a reprise of commit 90fda63fa115 ("treewide: fix up files
    incorrectly marked executable"), just with a different set of files (but
    with the same trivial shell scripting).
    
    So apparently we need to re-do this every five years or so, and Joe
    needs to just keep reminding me to do so ;)
    
    Reported-by: Joe Perches <joe@perches.com>
    Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64")
    Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326")
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tsnep: Fix TX queue stop/wake for multiple queues [+ + +]
Author: Gerhard Engleder <gerhard@engleder-embedded.com>
Date:   Tue Jan 24 20:14:40 2023 +0100

    tsnep: Fix TX queue stop/wake for multiple queues
    
    [ Upstream commit 3d53aaef4332245044b2f3688ac0ea10436c719c ]
    
    netif_stop_queue() and netif_wake_queue() act on TX queue 0. This is ok
    as long as only a single TX queue is supported. But support for multiple
    TX queues was introduced with 762031375d5c and I missed to adapt stop
    and wake of TX queues.
    
    Use netif_stop_subqueue() and netif_tx_wake_queue() to act on specific
    TX queue.
    
    Fixes: 762031375d5c ("tsnep: Support multiple TX/RX queue pairs")
    Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com>
    Link: https://lore.kernel.org/r/20230124191440.56887-1-gerhard@engleder-embedded.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc3: fix extcon dependency [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 18 10:01:41 2023 +0100

    usb: dwc3: fix extcon dependency
    
    [ Upstream commit 7d80dbd708c18c683dd34f79b600a05307707ce8 ]
    
    The dwc3 core support now links against the extcon subsystem,
    so it cannot be built-in when extcon is a loadable module:
    
    arm-linux-gnueabi-ld: drivers/usb/dwc3/core.o: in function `dwc3_get_extcon':
    core.c:(.text+0x572): undefined reference to `extcon_get_edev_by_phandle'
    arm-linux-gnueabi-ld: core.c:(.text+0x596): undefined reference to `extcon_get_extcon_dev'
    arm-linux-gnueabi-ld: core.c:(.text+0x5ea): undefined reference to `extcon_find_edev_by_node'
    
    There was already a Kconfig dependency in the dual-role support,
    but this is now needed for the entire dwc3 driver.
    
    It is still possible to build dwc3 without extcon, but this
    prevents it from being set to built-in when extcon is a loadable
    module.
    
    Fixes: d182c2e1bc92 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20230118090147.2126563-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_fs: Ensure ep0req is dequeued before free_request [+ + +]
Author: Udipto Goswami <quic_ugoswami@quicinc.com>
Date:   Thu Dec 15 10:59:06 2022 +0530

    usb: gadget: f_fs: Ensure ep0req is dequeued before free_request
    
    [ Upstream commit ce405d561b020e5a46340eb5146805a625dcacee ]
    
    As per the documentation, function usb_ep_free_request guarantees
    the request will not be queued or no longer be re-queued (or
    otherwise used). However, with the current implementation it
    doesn't make sure that the request in ep0 isn't reused.
    
    Fix this by dequeuing the ep0req on functionfs_unbind before
    freeing the request to align with the definition.
    
    Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
    Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
    Tested-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Link: https://lore.kernel.org/r/20221215052906.8993-3-quic_ugoswami@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait [+ + +]
Author: Udipto Goswami <quic_ugoswami@quicinc.com>
Date:   Thu Dec 15 10:59:05 2022 +0530

    usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
    
    [ Upstream commit 6a19da111057f69214b97c62fb0ac59023970850 ]
    
    While performing fast composition switch, there is a possibility that the
    process of ffs_ep0_write/ffs_ep0_read get into a race condition
    due to ep0req being freed up from functionfs_unbind.
    
    Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait
    by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't
    bounded so it can go ahead and mark the ep0req to NULL, and since there
    is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.
    
    Fix this by making a serialized execution between the two functions using
    a mutex_lock(ffs->mutex).
    
    Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
    Signed-off-by: Udipto Goswami <quic_ugoswami@quicinc.com>
    Tested-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Link: https://lore.kernel.org/r/20221215052906.8993-2-quic_ugoswami@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: ucsi: Ensure connector delayed work items are flushed [+ + +]
Author: Jack Pham <quic_jackp@quicinc.com>
Date:   Mon Jan 9 23:12:18 2023 -0800

    usb: ucsi: Ensure connector delayed work items are flushed
    
    [ Upstream commit fac4b8633fd682ecc8e9cff61cb3e33374a1c7e5 ]
    
    During ucsi_unregister() when destroying a connector's workqueue, there
    may still be pending delayed work items that haven't been scheduled yet.
    Because queue_delayed_work() uses a separate timer to schedule a work
    item, the destroy_workqueue() call is not aware of any pending items.
    Hence when a pending item's timer expires it would then try to queue on
    a dangling workqueue pointer.
    
    Fix this by keeping track of all work items in a list, so that prior to
    destroying the workqueue any pending items can be flushed.  Do this by
    calling mod_delayed_work() as that will cause pending items to get
    queued immediately, which then allows the ensuing destroy_workqueue() to
    implicitly drain all currently queued items to completion and free
    themselves.
    
    Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking")
    Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Co-developed-by: Linyu Yuan <quic_linyyuan@quicinc.com>
    Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
    Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20230110071218.26261-1-quic_jackp@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfio/type1: Respect IOMMU reserved regions in vfio_test_domain_fgsp() [+ + +]
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date:   Tue Jan 10 17:44:27 2023 +0100

    vfio/type1: Respect IOMMU reserved regions in vfio_test_domain_fgsp()
    
    [ Upstream commit 895c0747f726bb50c9b7a805613a61d1b6f9fa06 ]
    
    Since commit cbf7827bc5dc ("iommu/s390: Fix potential s390_domain
    aperture shrinking") the s390 IOMMU driver uses reserved regions for the
    system provided DMA ranges of PCI devices. Previously it reduced the
    size of the IOMMU aperture and checked it on each mapping operation.
    On current machines the system denies use of DMA addresses below 2^32 for
    all PCI devices.
    
    Usually mapping IOVAs in a reserved regions is harmless until a DMA
    actually tries to utilize the mapping. However on s390 there is
    a virtual PCI device called ISM which is implemented in firmware and
    used for cross LPAR communication. Unlike real PCI devices this device
    does not use the hardware IOMMU but inspects IOMMU translation tables
    directly on IOTLB flush (s390 RPCIT instruction). If it detects IOVA
    mappings outside the allowed ranges it goes into an error state. This
    error state then causes the device to be unavailable to the KVM guest.
    
    Analysing this we found that vfio_test_domain_fgsp() maps 2 pages at DMA
    address 0 irrespective of the IOMMUs reserved regions. Even if usually
    harmless this seems wrong in the general case so instead go through the
    freshly updated IOVA list and try to find a range that isn't reserved,
    and fits 2 pages, is PAGE_SIZE * 2 aligned. If found use that for
    testing for fine grained super pages.
    
    Fixes: af029169b8fd ("vfio/type1: Check reserved region conflict and update iova list")
    Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
    Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
    Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
    Link: https://lore.kernel.org/r/20230110164427.4051938-2-schnelle@linux.ibm.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
virtio-net: correctly enable callback during start_xmit [+ + +]
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Jan 17 11:47:07 2023 +0800

    virtio-net: correctly enable callback during start_xmit
    
    [ Upstream commit d71ebe8114b4bf622804b810f5e274069060a174 ]
    
    Commit a7766ef18b33("virtio_net: disable cb aggressively") enables
    virtqueue callback via the following statement:
    
            do {
                    if (use_napi)
                            virtqueue_disable_cb(sq->vq);
    
                    free_old_xmit_skbs(sq, false);
    
            } while (use_napi && kick &&
                   unlikely(!virtqueue_enable_cb_delayed(sq->vq)));
    
    When NAPI is used and kick is false, the callback won't be enabled
    here. And when the virtqueue is about to be full, the tx will be
    disabled, but we still don't enable tx interrupt which will cause a TX
    hang. This could be observed when using pktgen with burst enabled.
    
    TO be consistent with the logic that tries to disable cb only for
    NAPI, fixing this by trying to enable delayed callback only when NAPI
    is enabled when the queue is about to be full.
    
    Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively")
    Signed-off-by: Jason Wang <jasowang@redhat.com>
    Tested-by: Laurent Vivier <lvivier@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
w1: fix deadloop in __w1_remove_master_device() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 5 16:04:34 2022 +0800

    w1: fix deadloop in __w1_remove_master_device()
    
    [ Upstream commit 25d5648802f12ae486076ceca5d7ddf1fef792b2 ]
    
    I got a deadloop report while doing device(ds2482) add/remove test:
    
      [  162.241881] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      [  163.272251] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      [  164.296157] w1_master_driver w1_bus_master1: Waiting for w1_bus_master1 to become free: refcnt=1.
      ...
    
    __w1_remove_master_device() can't return, because the dev->refcnt is not zero.
    
    w1_add_master_device()                  |
      w1_alloc_dev()                        |
        atomic_set(&dev->refcnt, 2)         |
      kthread_run()                         |
                                            |__w1_remove_master_device()
                                            |  kthread_stop()
      // KTHREAD_SHOULD_STOP is set,        |
      // threadfn(w1_process) won't be      |
      // called.                            |
      kthread()                             |
                                            |  // refcnt will never be 0, it's deadloop.
                                            |  while (atomic_read(&dev->refcnt)) {...}
    
    After calling w1_add_master_device(), w1_process() is not really
    invoked, before w1_process() starting, if kthread_stop() is called
    in __w1_remove_master_device(), w1_process() will never be called,
    the refcnt can not be decreased, then it causes deadloop in remove
    function because of non-zero refcnt.
    
    We need to make sure w1_process() is really started, so move the
    set refcnt into w1_process() to fix this problem.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221205080434.3149205-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

w1: fix WARNING after calling w1_process() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 5 18:15:58 2022 +0800

    w1: fix WARNING after calling w1_process()
    
    [ Upstream commit 36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b ]
    
    I got the following WARNING message while removing driver(ds2482):
    
    ------------[ cut here ]------------
    do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire]
    WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0
    CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G                 N 6.1.0-rc3+ #307
    RIP: 0010:__might_sleep+0x98/0xa0
    Call Trace:
     exit_signals+0x6c/0x550
     do_exit+0x2b4/0x17e0
     kthread_exit+0x52/0x60
     kthread+0x16d/0x1e0
     ret_from_fork+0x1f/0x30
    
    The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(),
    set it to TASK_RUNNING when it breaks out of the loop to avoid the
    warning.
    
    Fixes: 3c52e4e62789 ("W1: w1_process, block or sleep")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221205101558.3599162-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: mac80211: Fix iTXQ AMPDU fragmentation handling [+ + +]
Author: Alexander Wetzel <alexander@wetzel-home.de>
Date:   Fri Jan 6 23:31:41 2023 +0100

    wifi: mac80211: Fix iTXQ AMPDU fragmentation handling
    
    commit 592234e941f1addaa598601c9227e3b72d608625 upstream.
    
    mac80211 must not enable aggregation wile transmitting a fragmented
    MPDU. Enforce that for mac80211 internal TX queues (iTXQs).
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Link: https://lore.kernel.org/oe-lkp/202301021738.7cd3e6ae-oliver.sang@intel.com
    Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20230106223141.98696-1-alexander@wetzel-home.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: mac80211: Proper mark iTXQs for resumption [+ + +]
Author: Alexander Wetzel <alexander@wetzel-home.de>
Date:   Fri Dec 30 13:18:49 2022 +0100

    wifi: mac80211: Proper mark iTXQs for resumption
    
    commit 4444bc2116aecdcde87dce80373540adc8bd478b upstream.
    
    When a running wake_tx_queue() call is aborted due to a hw queue stop
    the corresponding iTXQ is not always correctly marked for resumption:
    wake_tx_push_queue() can stops the queue run without setting
    @IEEE80211_TXQ_STOP_NETIF_TX.
    
    Without the @IEEE80211_TXQ_STOP_NETIF_TX flag __ieee80211_wake_txqs()
    will not schedule a new queue run and remaining frames in the queue get
    stuck till another frame is queued to it.
    
    Fix the issue for all drivers - also the ones with custom wake_tx_queue
    callbacks - by moving the logic into ieee80211_tx_dequeue() and drop the
    redundant @txqs_stopped.
    
    @IEEE80211_TXQ_STOP_NETIF_TX is also renamed to @IEEE80211_TXQ_DIRTY to
    better describe the flag.
    
    Fixes: c850e31f79f0 ("wifi: mac80211: add internal handler for wake_tx_queue")
    Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
    Link: https://lore.kernel.org/r/20221230121850.218810-1-alexander@wetzel-home.de
    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

wifi: rndis_wlan: Prevent buffer overflow in rndis_query_oid [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Wed Jan 11 18:50:31 2023 +0100

    wifi: rndis_wlan: Prevent buffer overflow in rndis_query_oid
    
    [ Upstream commit b870e73a56c4cccbec33224233eaf295839f228c ]
    
    Since resplen and respoffs are signed integers sufficiently
    large values of unsigned int len and offset members of RNDIS
    response will result in negative values of prior variables.
    This may be utilized to bypass implemented security checks
    to either extract memory contents by manipulating offset or
    overflow the data buffer via memcpy by manipulating both
    offset and len.
    
    Additionally assure that sum of resplen and respoffs does not
    overflow so buffer boundaries are kept.
    
    Fixes: 80f8c5b434f9 ("rndis_wlan: copy only useful data from rndis_command respond")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230111175031.7049-1-szymon.heidrich@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Mon Jan 9 22:57:13 2023 +0100

    x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL
    
    commit 5fa55950729d0762a787451dc52862c3f850f859 upstream.
    
    Baoquan reported that after triggering a crash the subsequent crash-kernel
    fails to boot about half of the time. It triggers a NULL pointer
    dereference in the periodic tick code.
    
    This happens because the legacy timer interrupt (IRQ0) is resent in
    software which happens in soft interrupt (tasklet) context. In this context
    get_irq_regs() returns NULL which leads to the NULL pointer dereference.
    
    The reason for the resend is a spurious APIC interrupt on the IRQ0 vector
    which is captured and leads to a resend when the legacy timer interrupt is
    enabled. This is wrong because the legacy PIC interrupts are level
    triggered and therefore should never be resent in software, but nothing
    ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not
    know about their trigger type.
    
    Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up.
    
    Fixes: a4633adcdbc1 ("[PATCH] genirq: add genirq sw IRQ-retrigger")
    Reported-by: Baoquan He <bhe@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Baoquan He <bhe@redhat.com>
    Link: https://lore.kernel.org/r/87mt6rjrra.ffs@tglx
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/sev: Add SEV-SNP guest feature negotiation support [+ + +]
Author: Nikunj A Dadhania <nikunj@amd.com>
Date:   Wed Jan 18 11:49:43 2023 +0530

    x86/sev: Add SEV-SNP guest feature negotiation support
    
    commit 8c29f016540532582721cec1dbf6d144873433ba upstream.
    
    The hypervisor can enable various new features (SEV_FEATURES[1:63]) and start a
    SNP guest. Some of these features need guest side implementation. If any of
    these features are enabled without it, the behavior of the SNP guest will be
    undefined.  It may fail booting in a non-obvious way making it difficult to
    debug.
    
    Instead of allowing the guest to continue and have it fail randomly later,
    detect this early and fail gracefully.
    
    The SEV_STATUS MSR indicates features which the hypervisor has enabled.  While
    booting, SNP guests should ascertain that all the enabled features have guest
    side implementation. In case a feature is not implemented in the guest, the
    guest terminates booting with GHCB protocol Non-Automatic Exit(NAE) termination
    request event, see "SEV-ES Guest-Hypervisor Communication Block Standardization"
    document (currently at https://developer.amd.com/wp-content/resources/56421.pdf),
    section "Termination Request".
    
    Populate SW_EXITINFO2 with mask of unsupported features that the hypervisor can
    easily report to the user.
    
    More details in the AMD64 APM Vol 2, Section "SEV_STATUS MSR".
    
      [ bp:
        - Massage.
        - Move snp_check_features() call to C code.
        Note: the CC:stable@ aspect here is to be able to protect older, stable
        kernels when running on newer hypervisors. Or not "running" but fail
        reliably and in a well-defined manner instead of randomly. ]
    
    Fixes: cbd3d4f7c4e5 ("x86/sev: Check SEV-SNP features support")
    Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20230118061943.534309-1-nikunj@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xen/pvcalls: free active map buffer on pvcalls_front_free_map [+ + +]
Author: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Date:   Tue Dec 20 14:50:13 2022 +0000

    xen/pvcalls: free active map buffer on pvcalls_front_free_map
    
    [ Upstream commit f57034cedeb6e00256313a2a6ee67f974d709b0b ]
    
    Data buffer for active map is allocated in alloc_active_ring and freed
    in free_active_ring function, which is used only for the error
    cleanup. pvcalls_front_release is calling pvcalls_front_free_map which
    ends foreign access for this buffer, but doesn't free allocated pages.
    Call free_active_ring to clean all allocated resources.
    
    Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/6a762ee32dd655cbb09a4aa0e2307e8919761311.1671531297.git.oleksii_moisieiev@epam.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>