Changelog in Linux kernel 6.6.54

 
ABI: testing: fix admv8818 attr description [+ + +]
Author: Antoniu Miclaus <[email protected]>
Date:   Tue Jul 2 11:18:50 2024 +0300

    ABI: testing: fix admv8818 attr description
    
    [ Upstream commit 7d34b4ad8cd2867b130b5b8d7d76d0d6092bd019 ]
    
    Fix description of the filter_mode_available attribute by pointing to
    the correct name of the attribute that can be written with valid values.
    
    Fixes: bf92d87d7c67 ("iio:filter:admv8818: Add sysfs ABI documentation")
    Signed-off-by: Antoniu Miclaus <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ACPI: CPPC: Fix MASK_VAL() usage [+ + +]
Author: Clément Léger <[email protected]>
Date:   Mon Aug 26 12:16:44 2024 +0200

    ACPI: CPPC: Fix MASK_VAL() usage
    
    [ Upstream commit 60949b7b805424f21326b450ca4f1806c06d982e ]
    
    MASK_VAL() was added as a way to handle bit_offset and bit_width for
    registers located in system memory address space. However, while suited
    for reading, it does not work for writing and result in corrupted
    registers when writing values with bit_offset > 0. Moreover, when a
    register is collocated with another one at the same address but with a
    different mask, the current code results in the other registers being
    overwritten with 0s. The write procedure for SYSTEM_MEMORY registers
    should actually read the value, mask it, update it and write it with the
    updated value. Moreover, since registers can be located in the same
    word, we must take care of locking the access before doing it. We should
    potentially use a global lock since we don't know in if register
    addresses aren't shared with another _CPC package but better not
    encourage vendors to do so. Assume that registers can use the same word
    inside a _CPC package and thus, use a per _CPC package lock.
    
    Fixes: 2f4a4d63a193 ("ACPI: CPPC: Use access_width over bit_width for system memory accesses")
    Signed-off-by: Clément Léger <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Dropped redundant semicolon ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe() [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Wed Jul 31 01:53:39 2024 +0300

    ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()
    
    [ Upstream commit 07442c46abad1d50ac82af5e0f9c5de2732c4592 ]
    
    In tps68470_pmic_opregion_probe() pointer 'dev' is compared to NULL which
    is useless.
    
    Fix this issue by removing unneeded check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: e13452ac3790 ("ACPI / PMIC: Add TI PMIC TPS68470 operation region driver")
    Suggested-by: Andy Shevchenko <[email protected]>
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Sakari Ailus <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [ rjw: Subject edit ]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ACPI: resource: Add another DMI match for the TongFang GMxXGxx [+ + +]
Author: Werner Sembach <[email protected]>
Date:   Tue Sep 10 11:40:06 2024 +0200

    ACPI: resource: Add another DMI match for the TongFang GMxXGxx
    
    commit a98cfe6ff15b62f94a44d565607a16771c847bc6 upstream.
    
    Internal documentation suggest that the TUXEDO Polaris 15 Gen5 AMD might
    have GMxXGxX as the board name instead of GMxXGxx.
    
    Adding both to be on the safe side.
    
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: All applicable <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ACPI: sysfs: validate return type of _STR method [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Tue Jul 9 22:37:24 2024 +0200

    ACPI: sysfs: validate return type of _STR method
    
    commit 4bb1e7d027413835b086aed35bc3f0713bc0f72b upstream.
    
    Only buffer objects are valid return values of _STR.
    
    If something else is returned description_show() will access invalid
    memory.
    
    Fixes: d1efe3c324ea ("ACPI: Add new sysfs interface to export device description")
    Cc: All applicable <[email protected]>
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ALSA: hda: cs35l41: fix module autoloading [+ + +]
Author: Yuntao Liu <[email protected]>
Date:   Thu Aug 15 09:13:12 2024 +0000

    ALSA: hda: cs35l41: fix module autoloading
    
    [ Upstream commit 48f1434a4632c7da1a6a94e159512ebddbe13392 ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from spi_device_id table.
    
    Fixes: 7b2f3eb492da ("ALSA: hda: cs35l41: Add support for CS35L41 in HDA systems")
    Signed-off-by: Yuntao Liu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB [+ + +]
Author: David Virag <[email protected]>
Date:   Sat Jul 13 19:58:32 2024 +0200

    arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB
    
    [ Upstream commit d281814b8f7a710a75258da883fb0dfe1329c031 ]
    
    All known jackpotlte variants have 4GB of RAM, let's use it all.
    RAM was set to 3GB from a mistake in the vendor provided DTS file.
    
    Fixes: 06874015327b ("arm64: dts: exynos: Add initial device tree support for Exynos7885 SoC")
    Signed-off-by: David Virag <[email protected]>
    Reviewed-by: Sam Protsenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs [+ + +]
Author: AngeloGioacchino Del Regno <[email protected]>
Date:   Thu Jul 25 09:22:43 2024 +0200

    arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs
    
    [ Upstream commit 2317d018b835842df0501d8f9e9efa843068a101 ]
    
    The speedbin eFuse reads a value 'x' from 0 to 7 and, in order to
    make that compatible with opp-supported-hw, it gets post processed
    as BIT(x).
    
    Change all of the 0x30 supported-hw to 0x20 to avoid getting
    duplicate OPPs for speedbin 4, and also change all of the 0x8 to
    0xcf because speedbins different from 4 and 5 do support 900MHz,
    950MHz, 1000MHz with the higher voltage of 850mV, 900mV, 950mV
    respectively.
    
    Fixes: f38ea593ad0d ("arm64: dts: mediatek: mt8186: Wire up GPU voltage/frequency scaling")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Wed Jul 31 11:44:08 2024 +0800

    arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled
    
    commit 09d385679487c58f0859c1ad4f404ba3df2f8830 upstream.
    
    USB 3.0 on xhci1 is not used, as the controller shares the same PHY as
    pcie1. The latter is enabled to support the M.2 PCIe WLAN card on this
    design.
    
    Mark USB 3.0 as disabled on this controller using the
    "mediatek,u3p-dis-msk" property.
    
    Reported-by: Nícolas F. R. A. Prado <[email protected]> #KernelCI
    Closes: https://lore.kernel.org/all/9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano/
    Fixes: b6267a396e1c ("arm64: dts: mediatek: cherry: Enable T-PHYs and USB XHCI controllers")
    Cc: [email protected]
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: mediatek: mt8195: Correct clock order for dp_intf* [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Fri Aug 2 15:09:50 2024 +0800

    arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*
    
    [ Upstream commit 51bc68debab9e30b50c6352315950f3cfc309b32 ]
    
    The clocks for dp_intf* device nodes are given in the wrong order,
    causing the binding validation to fail.
    
    Fixes: 6c2503b5856a ("arm64: dts: mt8195: Add dp-intf nodes")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Reviewed-by: Nícolas F. R. A. Prado <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Matthias Brugger <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent [+ + +]
Author: Qingqing Zhou <[email protected]>
Date:   Thu Jul 25 12:51:17 2024 +0530

    arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent
    
    commit 421688265d7f5d3ff4211982e7231765378bb64f upstream.
    
    The SMMUs on sa8775p are cache-coherent. GPU SMMU is marked as such,
    mark the APPS and PCIe ones as well.
    
    Fixes: 603f96d4c9d0 ("arm64: dts: qcom: add initial support for qcom sa8775p-ride")
    Fixes: 2dba7a613a6e ("arm64: dts: qcom: sa8775p: add the pcie smmu node")
    Cc: [email protected]
    Reviewed-by: Konrad Dybcio <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Qingqing Zhou <[email protected]>
    Rule: add
    Link: https://lore.kernel.org/stable/20240723075948.9545-1-quic_qqzhou%40quicinc.com
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Tue Jul 30 13:24:34 2024 +0100

    arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes
    
    [ Upstream commit ab39547f739236e7f16b8b0a51fdca95cc9cadd3 ]
    
    The RZ/G2UL SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB
    for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU.
    
    Despite the RZ/G2UL SoC being single-core, it has two instances of GICR.
    
    Fixes: cf40c9689e510 ("arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Tue Jul 30 13:24:36 2024 +0100

    arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes
    
    [ Upstream commit 833948fb2b63155847ab691a54800f801555429b ]
    
    The RZ/G2L(C) SoC is equipped with the GIC-600. The GICD is 64KiB +
    64KiB for the MBI alias (in total 128KiB), and the GICR is 128KiB per
    CPU.
    
    Fixes: 68a45525297b2 ("arm64: dts: renesas: Add initial DTSI for RZ/G2{L,LC} SoC's")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes [+ + +]
Author: Lad Prabhakar <[email protected]>
Date:   Tue Jul 30 13:24:35 2024 +0100

    arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes
    
    [ Upstream commit 45afa9eacb59b258d2e53c7f63430ea1e8344803 ]
    
    The RZ/V2L SoC is equipped with the GIC-600. The GICD is 64KiB + 64KiB
    for the MBI alias (in total 128KiB), and the GICR is 128KiB per CPU.
    
    Fixes: 7c2b8198f4f32 ("arm64: dts: renesas: Add initial DTSI for RZ/V2L SoC")
    Signed-off-by: Lad Prabhakar <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity [+ + +]
Author: Dragan Simic <[email protected]>
Date:   Mon Jul 15 19:44:20 2024 +0200

    arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity
    
    commit def33fb1191207f5afa6dcb681d71fef2a6c1293 upstream.
    
    All batches of the Pine64 Pinebook Pro, except the latest batch (as of 2024)
    whose hardware design was revised due to the component shortage, use a 1S
    lithium battery whose nominal/design capacity is 10,000 mAh, according to the
    battery datasheet. [1][2]  Let's correct the design full-charge value in the
    Pinebook Pro board dts, to improve the accuracy of the hardware description,
    and to hopefully improve the accuracy of the fuel gauge a bit on all units
    that don't belong to the latest batch.
    
    The above-mentioned latest batch uses a different 1S lithium battery with
    a slightly lower capacity, more precisely 9,600 mAh.  To make the fuel gauge
    work reliably on the latest batch, a sample battery would need to be sent to
    CellWise, to obtain its proprietary battery profile, whose data goes into
    "cellwise,battery-profile" in the Pinebook Pro board dts.  Without that data,
    the fuel gauge reportedly works unreliably, so changing the design capacity
    won't have any negative effects on the already unreliable operation of the
    fuel gauge in the Pinebook Pros that belong to the latest batch.
    
    According to the battery datasheet, its voltage can go as low as 2.75 V while
    discharging, but it's better to leave the current 3.0 V value in the dts file,
    because of the associated Pinebook Pro's voltage regulation issues.
    
    [1] https://wiki.pine64.org/index.php/Pinebook_Pro#Battery
    [2] https://files.pine64.org/doc/datasheet/pinebook/40110175P%203.8V%2010000mAh%E8%A7%84%E6%A0%BC%E4%B9%A6-14.pdf
    
    Fixes: c7c4d698cd28 ("arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts")
    Cc: [email protected]
    Cc: Marek Kraus <[email protected]>
    Signed-off-by: Dragan Simic <[email protected]>
    Link: https://lore.kernel.org/r/731f8ef9b1a867bcc730d19ed277c8c0534c0842.1721065172.git.dsimic@manjaro.org
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1 [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Tue Aug 27 21:18:16 2024 +0000

    arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1
    
    [ Upstream commit 735065e774dcfc62e38df01a535862138b6c92ed ]
    
    The vendor prefix for Hardkernel ODROID-M1 is incorrectly listed as
    rockchip. Use the proper hardkernel vendor prefix for this board, while
    at it also drop the redundant soc prefix.
    
    Fixes: fd3583267703 ("arm64: dts: rockchip: Add Hardkernel ODROID-M1 board")
    Reviewed-by: Aurelien Jarno <[email protected]>
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency [+ + +]
Author: Dragan Simic <[email protected]>
Date:   Sun Aug 4 23:10:24 2024 +0200

    arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency
    
    commit 8c51521de18755d4112a77a598a348b38d0af370 upstream.
    
    Increase the frequency of the PWM signal that drives the LED backlight of
    the Pinebook Pro's panel, from about 1.35 KHz (which equals to the PWM
    period of 740,740 ns), to exactly 8 kHz (which equals to the PWM period of
    125,000 ns).  Using a higher PWM frequency for the panel backlight, which
    reduces the flicker, can only be beneficial to the end users' eyes.
    
    On top of that, increasing the backlight PWM signal frequency reportedly
    eliminates the buzzing emitted from the Pinebook Pro's built-in speakers
    when certain backlight levels are set, which cause some weird interference
    with some of the components of the Pinebook Pro's audio chain.
    
    The old value for the backlight PWM period, i.e. 740,740 ns, is pretty much
    an arbitrary value that was selected during the very early bring-up of the
    Pinebook Pro, only because that value seemed to minimize horizontal line
    distortion on the display, which resulted from the old X.org drivers causing
    screen tearing when dragging windows around.  That's no longer an issue, so
    there are no reasons to stick with the old PWM period value.
    
    The lower and the upper backlight PWM frequency limits for the Pinebook Pro's
    panel, according to its datasheet, are 200 Hz and 10 kHz, respectively. [1]
    These changes still leave some headroom, which may have some positive effects
    on the lifetime expectancy of the panel's backlight LEDs.
    
    [1] https://files.pine64.org/doc/datasheet/PinebookPro/NV140FHM-N49_Rev.P0_20160804_201710235838.pdf
    
    Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
    Cc: [email protected]
    Reported-by: Nikola Radojevic <[email protected]>
    Signed-off-by: Dragan Simic <[email protected]>
    Tested-by: Nikola Radojević <[email protected]>
    Link: https://lore.kernel.org/r/2a23b6cfd8c0513e5b233b4006ee3d3ed09b824f.1722805655.git.dsimic@manjaro.org
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Thu Aug 1 13:12:32 2024 -0500

    arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations
    
    [ Upstream commit 1a314099b7559690fe23cdf3300dfff6e830ecb1 ]
    
    The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at
    0xa7000000. These are reversed in DT. While both C6x can access either
    region, so this is not normally a problem, but if we start restricting
    the memory each core can access (such as with firewalls) the cores
    accessing the regions for the wrong core will not work. Fix this here.
    
    Fixes: fae14a1cb8dd ("arm64: dts: ti: Add k3-j721e-beagleboneai64")
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Thu Aug 1 13:12:31 2024 -0500

    arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations
    
    [ Upstream commit 9f3814a7c06b7c7296cf8c1622078ad71820454b ]
    
    The DMA carveout for the C6x core 0 is at 0xa6000000 and core 1 is at
    0xa7000000. These are reversed in DT. While both C6x can access either
    region, so this is not normally a problem, but if we start restricting
    the memory each core can access (such as with firewalls) the cores
    accessing the regions for the wrong core will not work. Fix this here.
    
    Fixes: f46d16cf5b43 ("arm64: dts: ti: k3-j721e-sk: Add DDR carveout memory nodes")
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Nishanth Menon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a [+ + +]
Author: D Scott Phillips <[email protected]>
Date:   Tue Aug 27 14:17:01 2024 -0700

    arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a
    
    commit db0d8a84348b876df7c4276f0cbce5df3b769f5f upstream.
    
    The ampere1a cpu is affected by erratum AC04_CPU_10 which is the same
    bug as AC03_CPU_38. Add ampere1a to the AC03_CPU_38 workaround midr list.
    
    Cc: <[email protected]>
    Signed-off-by: D Scott Phillips <[email protected]>
    Acked-by: Oliver Upton <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: esr: Define ESR_ELx_EC_* constants as UL [+ + +]
Author: Anastasia Belova <[email protected]>
Date:   Tue Sep 10 11:50:16 2024 +0300

    arm64: esr: Define ESR_ELx_EC_* constants as UL
    
    commit b6db3eb6c373b97d9e433530d748590421bbeea7 upstream.
    
    Add explicit casting to prevent expantion of 32th bit of
    u32 into highest half of u64 in several places.
    
    For example, in inject_abt64:
    ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT = 0x24 << 26.
    This operation's result is int with 1 in 32th bit.
    While casting this value into u64 (esr is u64) 1
    fills 32 highest bits.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Cc: <[email protected]>
    Fixes: aa8eff9bfbd5 ("arm64: KVM: fault injection into a guest")
    Signed-off-by: Anastasia Belova <[email protected]>
    Acked-by: Marc Zyngier <[email protected]>
    Link: https://lore.kernel.org/stable/20240910085016.32120-1-abelova%40astralinux.ru
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: signal: Fix some under-bracketed UAPI macros [+ + +]
Author: Dave Martin <[email protected]>
Date:   Mon Jul 29 16:20:05 2024 +0100

    arm64: signal: Fix some under-bracketed UAPI macros
    
    [ Upstream commit fc2220c9b15828319b09384e68399b4afc6276d9 ]
    
    A few SME-related sigcontext UAPI macros leave an argument
    unprotected from misparsing during macro expansion.
    
    Add parentheses around references to macro arguments where
    appropriate.
    
    Signed-off-by: Dave Martin <[email protected]>
    Fixes: ee072cf70804 ("arm64/sme: Implement signal handling for ZT")
    Fixes: 39782210eb7e ("arm64/sme: Implement ZA signal handling")
    Reviewed-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros [+ + +]
Author: Calvin Owens <[email protected]>
Date:   Mon Jul 29 17:05:51 2024 +0100

    ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros
    
    [ Upstream commit 89a906dfa8c3b21b3e5360f73c49234ac1eb885b ]
    
    Floating point instructions in userspace can crash some arm kernels
    built with clang/LLD 17.0.6:
    
        BUG: unsupported FP instruction in kernel mode
        FPEXC == 0xc0000780
        Internal error: Oops - undefined instruction: 0 [#1] ARM
        CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1
        Hardware name: BCM2835
        PC is at vfp_support_entry+0xc8/0x2cc
        LR is at do_undefinstr+0xa8/0x250
        pc : [<c0101d50>]    lr : [<c010a80c>]    psr: a0000013
        sp : dc8d1f68  ip : 60000013  fp : bedea19c
        r10: ec532b17  r9 : 00000010  r8 : 0044766c
        r7 : c0000780  r6 : ec532b17  r5 : c1c13800  r4 : dc8d1fb0
        r3 : c10072c4  r2 : c0101c88  r1 : ec532b17  r0 : 0044766c
        Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
        Control: 00c5387d  Table: 0251c008  DAC: 00000051
        Register r0 information: non-paged memory
        Register r1 information: vmalloc memory
        Register r2 information: non-slab/vmalloc memory
        Register r3 information: non-slab/vmalloc memory
        Register r4 information: 2-page vmalloc region
        Register r5 information: slab kmalloc-cg-2k
        Register r6 information: vmalloc memory
        Register r7 information: non-slab/vmalloc memory
        Register r8 information: non-paged memory
        Register r9 information: zero-size pointer
        Register r10 information: vmalloc memory
        Register r11 information: non-paged memory
        Register r12 information: non-paged memory
        Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b)
        Stack: (0xdc8d1f68 to 0xdc8d2000)
        1f60:                   0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0
        1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010
        1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188
        1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c
        1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000
        Call trace:
        [<c0101d50>] (vfp_support_entry) from [<c010a80c>] (do_undefinstr+0xa8/0x250)
        [<c010a80c>] (do_undefinstr) from [<c0100f10>] (__und_usr+0x70/0x80)
        Exception stack(0xdc8d1fb0 to 0xdc8d1ff8)
        1fa0:                                     b6f68af8 00448fc0 00000000 bedea188
        1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c
        1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff
        Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10)
        ---[ end trace 0000000000000000 ]---
        Kernel panic - not syncing: Fatal exception in interrupt
        ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
    
    This is a minimal userspace reproducer on a Raspberry Pi Zero W:
    
        #include <stdio.h>
        #include <math.h>
    
        int main(void)
        {
                double v = 1.0;
                printf("%fn", NAN + *(volatile double *)&v);
                return 0;
        }
    
    Another way to consistently trigger the oops is:
    
        calvin@raspberry-pi-zero-w ~$ python -c "import json"
    
    The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n,
    because the pr_debug() calls act as barriers even when not activated.
    
    This is the output from the same kernel source built with the same
    compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as
    expected:
    
        VFP: bounce: trigger ec532b17 fpexc c0000780
        VFP: emulate: INST=0xee377b06 SCR=0x00000000
        VFP: bounce: trigger eef1fa10 fpexc c0000780
        VFP: emulate: INST=0xeeb40b40 SCR=0x00000000
        VFP: raising exceptions 30000000
    
        calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer
        nan
    
    Crudely grepping for vmsr/vmrs instructions in the otherwise nearly
    idential text for vfp_support_entry() makes the problem obvious:
    
        vmlinux.llvm.good [0xc0101cb8] <+48>:  vmrs   r7, fpexc
        vmlinux.llvm.good [0xc0101cd8] <+80>:  vmsr   fpexc, r0
        vmlinux.llvm.good [0xc0101d20] <+152>: vmsr   fpexc, r7
        vmlinux.llvm.good [0xc0101d38] <+176>: vmrs   r4, fpexc
        vmlinux.llvm.good [0xc0101d6c] <+228>: vmrs   r0, fpscr
        vmlinux.llvm.good [0xc0101dc4] <+316>: vmsr   fpexc, r0
        vmlinux.llvm.good [0xc0101dc8] <+320>: vmrs   r0, fpsid
        vmlinux.llvm.good [0xc0101dcc] <+324>: vmrs   r6, fpscr
        vmlinux.llvm.good [0xc0101e10] <+392>: vmrs   r10, fpinst
        vmlinux.llvm.good [0xc0101eb8] <+560>: vmrs   r10, fpinst2
    
        vmlinux.llvm.bad  [0xc0101cb8] <+48>:  vmrs   r7, fpexc
        vmlinux.llvm.bad  [0xc0101cd8] <+80>:  vmsr   fpexc, r0
        vmlinux.llvm.bad  [0xc0101d20] <+152>: vmsr   fpexc, r7
        vmlinux.llvm.bad  [0xc0101d30] <+168>: vmrs   r0, fpscr
        vmlinux.llvm.bad  [0xc0101d50] <+200>: vmrs   r6, fpscr  <== BOOM!
        vmlinux.llvm.bad  [0xc0101d6c] <+228>: vmsr   fpexc, r0
        vmlinux.llvm.bad  [0xc0101d70] <+232>: vmrs   r0, fpsid
        vmlinux.llvm.bad  [0xc0101da4] <+284>: vmrs   r10, fpinst
        vmlinux.llvm.bad  [0xc0101df8] <+368>: vmrs   r4, fpexc
        vmlinux.llvm.bad  [0xc0101e5c] <+468>: vmrs   r10, fpinst2
    
    I think LLVM's reordering is valid as the code is currently written: the
    compiler doesn't know the instructions have side effects in hardware.
    
    Fix by using "asm volatile" in fmxr() and fmrx(), so they cannot be
    reordered with respect to each other. The original compiler now produces
    working kernels on my hardware with DYNAMIC_DEBUG=n.
    
    This is the relevant piece of the diff of the vfp_support_entry() text,
    from the original oopsing kernel to a working kernel with this patch:
    
             vmrs r0, fpscr
             tst r0, #4096
             bne 0xc0101d48
             tst r0, #458752
             beq 0xc0101ecc
             orr r7, r7, #536870912
             ldr r0, [r4, #0x3c]
             mov r9, #16
            -vmrs r6, fpscr
             orr r9, r9, #251658240
             add r0, r0, #4
             str r0, [r4, #0x3c]
             mvn r0, #159
             sub r0, r0, #-1207959552
             and r0, r7, r0
             vmsr fpexc, r0
             vmrs r0, fpsid
            +vmrs r6, fpscr
             and r0, r0, #983040
             cmp r0, #65536
             bne 0xc0101d88
    
    Fixes: 4708fb041346 ("ARM: vfp: Reimplement VFP exception entry in C code")
    Signed-off-by: Calvin Owens <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sat Aug 31 12:11:28 2024 +0200

    ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl
    
    commit 1b0e32753d8550908dff8982410357b5114be78c upstream.
    
    The property is "fsl,pins", not "fsl,pin".  Wrong property means the pin
    configuration was not applied.  Fixes dtbs_check warnings:
    
      imx6ul-geam.dtb: pinctrl@20e0000: tscgrp: 'fsl,pins' is a required property
      imx6ul-geam.dtb: pinctrl@20e0000: tscgrp: 'fsl,pin' does not match any of the regexes: 'pinctrl-[0-9]+'
    
    Cc: [email protected]
    Fixes: a58e4e608bc8 ("ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL initial support")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Michael Trimarchi <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Wed Aug 28 11:56:36 2024 +0200

    ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property
    
    [ Upstream commit 0e49cfe364dea4345551516eb2fe53135a10432b ]
    
    There is no "fsl,phy" property in pin controller pincfg nodes:
    
      imx7d-zii-rmu2.dtb: pinctrl@302c0000: enet1phyinterruptgrp: 'fsl,pins' is a required property
      imx7d-zii-rmu2.dtb: pinctrl@302c0000: enet1phyinterruptgrp: 'fsl,phy' does not match any of the regexes: 'pinctrl-[0-9]+'
    
    Fixes: f496e6750083 ("ARM: dts: Add ZII support for ZII i.MX7 RMU2 board")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks [+ + +]
Author: Alexander Dahl <[email protected]>
Date:   Wed Aug 21 07:51:36 2024 +0200

    ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks
    
    [ Upstream commit d355c895fa4ddd8bec15569eee540baeed7df8c5 ]
    
    The RTC and RTT peripherals use the timing domain slow clock (TD_SLCK),
    sourced from the 32.768 kHz crystal oscillator or slow rc oscillator.
    
    The previously used Monitoring domain slow clock (MD_SLCK) is sourced
    from an internal RC oscillator which is most probably not precise enough
    for real time clock purposes.
    
    Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
    Fixes: 5f6b33f46346 ("ARM: dts: sam9x60: add rtt")
    Signed-off-by: Alexander Dahl <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [claudiu.beznea: removed () around the last commit description paragraph,
     removed " in front of "timing domain slow clock", described that
     TD_SLCK can also be sourced from slow rc oscillator]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: microchip: sama7g5: Fix RTT clock [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Mon Aug 26 19:53:20 2024 +0300

    ARM: dts: microchip: sama7g5: Fix RTT clock
    
    [ Upstream commit 867bf1923200e6ad82bad0289f43bf20b4ac7ff9 ]
    
    According to datasheet, Chapter 34. Clock Generator, section 34.2,
    Embedded characteristics, source clock for RTT is the TD_SLCK, registered
    with ID 1 by the slow clock controller driver. Fix RTT clock.
    
    Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: versatile: fix OF node leak in CPUs prepare [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Aug 26 07:49:33 2024 +0200

    ARM: versatile: fix OF node leak in CPUs prepare
    
    [ Upstream commit f2642d97f2105ed17b2ece0c597450f2ff95d704 ]
    
    Machine code is leaking OF node reference from of_find_matching_node()
    in realview_smp_prepare_cpus().
    
    Fixes: 5420b4b15617 ("ARM: realview: add an DT SMP boot method")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Liviu Dudau <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ASoC: loongson: fix error release [+ + +]
Author: tangbin <[email protected]>
Date:   Tue Sep 3 17:06:20 2024 +0800

    ASoC: loongson: fix error release
    
    [ Upstream commit 97688a9c5b1fd2b826c682cdfa36d411a5c99828 ]
    
    In function loongson_card_parse_of(), when get device_node
    'codec' failed, the function of_node_put(codec) should not
    be invoked, thus fix error release.
    
    Fixes: d24028606e76 ("ASoC: loongson: Add Loongson ASoC Sound Card Support")
    Signed-off-by: tangbin <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error [+ + +]
Author: Ma Ke <[email protected]>
Date:   Fri Aug 30 22:31:54 2024 +0800

    ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error
    
    commit fcca6d05ef49d5650514ea1dcfd12e4ae3ff2be6 upstream.
    
    Return devm_of_clk_add_hw_provider() in order to transfer the error, if it
    fails due to resource allocation failure or device tree clock provider
    registration failure.
    
    Cc: [email protected]
    Fixes: ebbfabc16d23 ("ASoC: rt5682: Add CCF usage for providing I2S clks")
    Signed-off-by: Ma Ke <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error [+ + +]
Author: Ma Ke <[email protected]>
Date:   Wed Jul 17 19:54:36 2024 +0800

    ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error
    
    [ Upstream commit 3ff810b9bebe5578a245cfa97c252ab602e703f1 ]
    
    Return devm_of_clk_add_hw_provider() in order to transfer the error, if it
    fails due to resource allocation failure or device tree clock provider
    registration failure.
    
    Fixes: bdd229ab26be ("ASoC: rt5682s: Add driver for ALC5682I-VS codec")
    Signed-off-by: Ma Ke <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2781-i2c: Drop weird GPIO code [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Wed Aug 7 17:02:32 2024 +0200

    ASoC: tas2781-i2c: Drop weird GPIO code
    
    [ Upstream commit c2c0b67dca3cb3b3cea0dd60075a1c5ba77e2fcd ]
    
    The tas2781-i2c driver gets an IRQ from either ACPI or device tree,
    then proceeds to check if the IRQ has a corresponding GPIO and in
    case it does enforce the GPIO as input and set a label on it.
    
    This is abuse of the API:
    
    - First we cannot guarantee that the numberspaces of the GPIOs and
      the IRQs are the same, i.e that an IRQ number corresponds to
      a GPIO number like that.
    
    - Second, GPIO chips and IRQ chips should be treated as orthogonal
      APIs, the irqchip needs to ascertain that the backing GPIO line
      is set to input etc just using the irqchip.
    
    - Third it is using the legacy <linux/gpio.h> API which should not
      be used in new code yet this was added just a year ago.
    
    Delete the offending code.
    
    If this creates problems the GPIO and irqchip maintainers can help
    to fix the issues.
    
    It *should* not create any problems, because the irq isn't
    used anywhere in the driver, it's just obtained and then
    left unused.
    
    Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver")
    Signed-off-by: Linus Walleij <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2781-i2c: Get the right GPIO line [+ + +]
Author: Linus Walleij <[email protected]>
Date:   Wed Aug 7 17:02:33 2024 +0200

    ASoC: tas2781-i2c: Get the right GPIO line
    
    [ Upstream commit 1c4b509edad15192bfb64c81d3c305bbae8070db ]
    
    The code is obtaining a GPIO reset using the reset GPIO
    name "reset-gpios", but the gpiolib is already adding the
    suffix "-gpios" to anything passed to this function and
    will be looking for "reset-gpios-gpios" which is most
    certainly not what the author desired.
    
    Fix it up.
    
    Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver")
    Signed-off-by: Linus Walleij <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2781: remove unused acpi_subysystem_id [+ + +]
Author: Gergo Koteles <[email protected]>
Date:   Fri Feb 9 06:59:34 2024 +0100

    ASoC: tas2781: remove unused acpi_subysystem_id
    
    [ Upstream commit 4089d82e67a9967fc5bf2b4e5ef820d67fe73924 ]
    
    The acpi_subysystem_id is only written and freed, not read, so
    unnecessary.
    
    Signed-off-by: Gergo Koteles <[email protected]>
    Link: https://lore.kernel.org/r/454639336be28d2b50343e9c8366a56b0975e31d.1707456753.git.soyer@irl.hu
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: c2c0b67dca3c ("ASoC: tas2781-i2c: Drop weird GPIO code")
    Signed-off-by: Sasha Levin <[email protected]>

ASoC: tas2781: Use of_property_read_reg() [+ + +]
Author: Rob Herring (Arm) <[email protected]>
Date:   Tue Jul 2 15:54:01 2024 -0600

    ASoC: tas2781: Use of_property_read_reg()
    
    [ Upstream commit 31a45f9190b5b4f5cd8cdec8471babd5215eee04 ]
    
    Replace the open-coded parsing of "reg" with of_property_read_reg().
    The #ifdef is also easily replaced with IS_ENABLED().
    
    Signed-off-by: Rob Herring (Arm) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: c2c0b67dca3c ("ASoC: tas2781-i2c: Drop weird GPIO code")
    Signed-off-by: Sasha Levin <[email protected]>

 
ata: libata-scsi: Fix ata_msense_control() CDL page reporting [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Mon Sep 23 18:14:36 2024 +0900

    ata: libata-scsi: Fix ata_msense_control() CDL page reporting
    
    commit 0e9a2990a93f27daa643b6fa73cfa47b128947a7 upstream.
    
    When the user requests the ALL_SUB_MPAGES mode sense page,
    ata_msense_control() adds the CDL_T2A_SUB_MPAGE twice instead of adding
    the CDL_T2A_SUB_MPAGE and CDL_T2B_SUB_MPAGE pages information. Correct
    the second call to ata_msense_control_spgt2() to report the
    CDL_T2B_SUB_MPAGE page.
    
    Fixes: 673b2fe6ff1d ("scsi: ata: libata-scsi: Add support for CDL pages mode sense")
    Cc: [email protected]
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data [+ + +]
Author: Niklas Cassel <[email protected]>
Date:   Mon Sep 9 17:42:38 2024 +0200

    ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data
    
    [ Upstream commit e5dd410acb34c7341a0a93b429dcf3dabf9e3323 ]
    
    When ata_qc_complete() schedules a command for EH using
    ata_qc_schedule_eh(), blk_abort_request() will be called, which leads to
    req->q->mq_ops->timeout() / scsi_timeout() being called.
    
    scsi_timeout(), if the LLDD has no abort handler (libata has no abort
    handler), will set host byte to DID_TIME_OUT, and then call
    scsi_eh_scmd_add() to add the command to EH.
    
    Thus, when commands first enter libata's EH strategy_handler, all the
    commands that have been added to EH will have DID_TIME_OUT set.
    
    libata has its own flag (AC_ERR_TIMEOUT), that it sets for commands that
    have not received a completion at the time of entering EH.
    
    Thus, libata doesn't really care about DID_TIME_OUT at all, and currently
    clears the host byte at the end of EH, in ata_scsi_qc_complete(), before
    scsi_eh_finish_cmd() is called.
    
    However, this clearing in ata_scsi_qc_complete() is currently only done
    for commands that are not ATA passthrough commands.
    
    Since the host byte is visible in the completion that we return to user
    space for ATA passthrough commands, for ATA passthrough commands that got
    completed via EH (commands with sense data), the user will incorrectly see:
    ATA pass-through(16): transport error: Host_status=0x03 [DID_TIME_OUT]
    
    Fix this by moving the clearing of the host byte (which is currently only
    done for commands that are not ATA passthrough commands) from
    ata_scsi_qc_complete() to the start of EH (regardless if the command is
    ATA passthrough or not).
    
    While at it, use the proper helper function to clear the host byte, rather
    than open coding the clearing.
    
    This will make sure that we:
    -Correctly clear DID_TIME_OUT for both ATA passthrough commands and
     commands that are not ATA passthrough commands.
    -Do not needlessly clear the host byte for commands that did not go via EH.
     ata_scsi_qc_complete() is called both for commands that are completed
     normally (without going via EH), and for commands that went via EH,
     however, only commands that went via EH will have DID_TIME_OUT set.
    
    Fixes: 24aeebbf8ea9 ("scsi: ata: libata: Change ata_eh_request_sense() to not set CHECK_CONDITION")
    Reported-by: Igor Pylypiv <[email protected]>
    Closes: https://lore.kernel.org/linux-ide/[email protected]/
    Signed-off-by: Niklas Cassel <[email protected]>
    Tested-by: Igor Pylypiv <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bareudp: Pull inner IP header in bareudp_udp_encap_recv(). [+ + +]
Author: Guillaume Nault <[email protected]>
Date:   Wed Sep 11 11:20:58 2024 +0200

    bareudp: Pull inner IP header in bareudp_udp_encap_recv().
    
    [ Upstream commit 45fa29c85117170b0508790f878b13ec6593c888 ]
    
    Bareudp reads the inner IP header to get the ECN value. Therefore, it
    needs to ensure that it's part of the skb's linear data.
    
    This is similar to the vxlan and geneve fixes for that same problem:
      * commit f7789419137b ("vxlan: Pull inner IP header in vxlan_rcv().")
      * commit 1ca1ba465e55 ("geneve: make sure to pull inner header in
        geneve_rx()")
    
    Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
    Signed-off-by: Guillaume Nault <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/5205940067c40218a70fbb888080466b2fc288db.1726046181.git.gnault@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bareudp: Pull inner IP header on xmit. [+ + +]
Author: Guillaume Nault <[email protected]>
Date:   Wed Sep 11 11:21:05 2024 +0200

    bareudp: Pull inner IP header on xmit.
    
    [ Upstream commit c471236b2359e6b27388475dd04fff0a5e2bf922 ]
    
    Both bareudp_xmit_skb() and bareudp6_xmit_skb() read their skb's inner
    IP header to get its ECN value (with ip_tunnel_ecn_encap()). Therefore
    we need to ensure that the inner IP header is part of the skb's linear
    data.
    
    Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
    Signed-off-by: Guillaume Nault <[email protected]>
    Reviewed-by: Willem de Bruijn <[email protected]>
    Link: https://patch.msgid.link/267328222f0a11519c6de04c640a4f87a38ea9ed.1726046181.git.gnault@redhat.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:27 2024 +0800

    block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()
    
    [ Upstream commit 0e456dba86c7f9a19792204a044835f1ca2c8dbb ]
    
    Consider the following merge chain:
    
    Process 1       Process 2       Process 3       Process 4
     (BIC1)          (BIC2)          (BIC3)          (BIC4)
      Λ                |               |               |
       \--------------\ \-------------\ \-------------\|
                       V               V               V
      bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    
    IO from Process 1 will get bfqf2 from BIC1 first, then
    bfq_setup_cooperator() will found bfqq2 already merged to bfqq3 and then
    handle this IO from bfqq3. However, the merge chain can be much deeper
    and bfqq3 can be merged to other bfqq as well.
    
    Fix this problem by iterating to the last bfqq in
    bfq_setup_cooperator().
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: don't break merge chain in bfq_split_bfqq() [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:28 2024 +0800

    block, bfq: don't break merge chain in bfq_split_bfqq()
    
    [ Upstream commit 42c306ed723321af4003b2a41bb73728cab54f85 ]
    
    Consider the following scenario:
    
        Process 1       Process 2       Process 3       Process 4
         (BIC1)          (BIC2)          (BIC3)          (BIC4)
          Λ               |               |                |
           \-------------\ \-------------\ \--------------\|
                          V               V                V
          bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    ref    0              1               2                4
    
    If Process 1 issue a new IO and bfqq2 is found, and then bfq_init_rq()
    decide to spilt bfqq2 by bfq_split_bfqq(). Howerver, procress reference
    of bfqq2 is 1 and bfq_split_bfqq() just clear the coop flag, which will
    break the merge chain.
    
    Expected result: caller will allocate a new bfqq for BIC1
    
        Process 1       Process 2       Process 3       Process 4
         (BIC1)          (BIC2)          (BIC3)          (BIC4)
                          |               |                |
                           \-------------\ \--------------\|
                                          V                V
          bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
    ref    0              0               1                3
    
    Since the condition is only used for the last bfqq4 when the previous
    bfqq2 and bfqq3 are already splited. Fix the problem by checking if
    bfqq is the last one in the merge chain as well.
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: fix possible UAF for bfqq->bic with merge chain [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 2 21:03:26 2024 +0800

    block, bfq: fix possible UAF for bfqq->bic with merge chain
    
    [ Upstream commit 18ad4df091dd5d067d2faa8fce1180b79f7041a7 ]
    
    1) initial state, three tasks:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
                      |  Λ            |  Λ            |  Λ
                      |  |            |  |            |  |
                      V  |            V  |            V  |
                      bfqq1           bfqq2           bfqq3
    process ref:       1                1               1
    
    2) bfqq1 merged to bfqq2:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
                      |               |               |  Λ
                      \--------------\|               |  |
                                      V               V  |
                      bfqq1--------->bfqq2            bfqq3
    process ref:       0                2               1
    
    3) bfqq2 merged to bfqq3:
    
                    Process 1       Process 2       Process 3
                     (BIC1)          (BIC2)          (BIC3)
             here -> Λ                |               |
                      \--------------\ \-------------\|
                                      V               V
                      bfqq1--------->bfqq2---------->bfqq3
    process ref:       0                1               3
    
    In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
    get bfqq3 through merge chain, and finially handle IO by bfqq3.
    Howerver, current code will think bfqq2 is owned by BIC1, like initial
    state, and set bfqq2->bic to BIC1.
    
    bfq_insert_request
    -> by Process 1
     bfqq = bfq_init_rq(rq)
      bfqq = bfq_get_bfqq_handle_split
       bfqq = bic_to_bfqq
       -> get bfqq2 from BIC1
     bfqq->ref++
     rq->elv.priv[0] = bic
     rq->elv.priv[1] = bfqq
     if (bfqq_process_refs(bfqq) == 1)
      bfqq->bic = bic
      -> record BIC1 to bfqq2
    
      __bfq_insert_request
       new_bfqq = bfq_setup_cooperator
       -> get bfqq3 from bfqq2->new_bfqq
       bfqq_request_freed(bfqq)
       new_bfqq->ref++
       rq->elv.priv[1] = new_bfqq
       -> handle IO by bfqq3
    
    Fix the problem by checking bfqq is from merge chain fist. And this
    might fix a following problem reported by our syzkaller(unreproducible):
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
    BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
    BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
    Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595
    
    CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G             L     6.6.0-07439-gba2303cacfda #6
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
    Workqueue: kblockd blk_mq_requeue_work
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:364 [inline]
     print_report+0x10d/0x610 mm/kasan/report.c:475
     kasan_report+0x8e/0xc0 mm/kasan/report.c:588
     bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
     bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
     bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
     bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
     bfq_init_rq block/bfq-iosched.c:6876 [inline]
     bfq_insert_request block/bfq-iosched.c:6254 [inline]
     bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
     blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
     blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
     </TASK>
    
    Allocated by task 20776:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
     kasan_slab_alloc include/linux/kasan.h:188 [inline]
     slab_post_alloc_hook mm/slab.h:763 [inline]
     slab_alloc_node mm/slub.c:3458 [inline]
     kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
     ioc_create_icq block/blk-ioc.c:370 [inline]
     ioc_find_get_icq+0x180/0xaa0 block/blk-ioc.c:436
     bfq_prepare_request+0x39/0xf0 block/bfq-iosched.c:6812
     blk_mq_rq_ctx_init.isra.7+0x6ac/0xa00 block/blk-mq.c:403
     __blk_mq_alloc_requests+0xcc0/0x1070 block/blk-mq.c:517
     blk_mq_get_new_requests block/blk-mq.c:2940 [inline]
     blk_mq_submit_bio+0x624/0x27c0 block/blk-mq.c:3042
     __submit_bio+0x331/0x6f0 block/blk-core.c:624
     __submit_bio_noacct_mq block/blk-core.c:703 [inline]
     submit_bio_noacct_nocheck+0x816/0xb40 block/blk-core.c:732
     submit_bio_noacct+0x7a6/0x1b50 block/blk-core.c:826
     xlog_write_iclog+0x7d5/0xa00 fs/xfs/xfs_log.c:1958
     xlog_state_release_iclog+0x3b8/0x720 fs/xfs/xfs_log.c:619
     xlog_cil_push_work+0x19c5/0x2270 fs/xfs/xfs_log_cil.c:1330
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    Freed by task 946:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     kasan_set_track+0x25/0x30 mm/kasan/common.c:52
     kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522
     ____kasan_slab_free mm/kasan/common.c:236 [inline]
     __kasan_slab_free+0x12c/0x1c0 mm/kasan/common.c:244
     kasan_slab_free include/linux/kasan.h:164 [inline]
     slab_free_hook mm/slub.c:1815 [inline]
     slab_free_freelist_hook mm/slub.c:1841 [inline]
     slab_free mm/slub.c:3786 [inline]
     kmem_cache_free+0x118/0x6f0 mm/slub.c:3808
     rcu_do_batch+0x35c/0xe30 kernel/rcu/tree.c:2189
     rcu_core+0x819/0xd90 kernel/rcu/tree.c:2462
     __do_softirq+0x1b0/0x7a2 kernel/softirq.c:553
    
    Last potentially related work creation:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:492
     __call_rcu_common kernel/rcu/tree.c:2712 [inline]
     call_rcu+0xce/0x1020 kernel/rcu/tree.c:2826
     ioc_destroy_icq+0x54c/0x830 block/blk-ioc.c:105
     ioc_release_fn+0xf0/0x360 block/blk-ioc.c:124
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    Second to last potentially related work creation:
     kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
     __kasan_record_aux_stack+0xaf/0xc0 mm/kasan/generic.c:492
     __call_rcu_common kernel/rcu/tree.c:2712 [inline]
     call_rcu+0xce/0x1020 kernel/rcu/tree.c:2826
     ioc_destroy_icq+0x54c/0x830 block/blk-ioc.c:105
     ioc_release_fn+0xf0/0x360 block/blk-ioc.c:124
     process_one_work kernel/workqueue.c:2627 [inline]
     process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
     worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
     kthread+0x33c/0x440 kernel/kthread.c:388
     ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
    
    The buggy address belongs to the object at ffff888123839d68
     which belongs to the cache bfq_io_cq of size 1360
    The buggy address is located 336 bytes inside of
     freed 1360-byte region [ffff888123839d68, ffff88812383a2b8)
    
    The buggy address belongs to the physical page:
    page:ffffea00048e0e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88812383f588 pfn:0x123838
    head:ffffea00048e0e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    flags: 0x17ffffc0000a40(workingset|slab|head|node=0|zone=2|lastcpupid=0x1fffff)
    page_type: 0xffffffff()
    raw: 0017ffffc0000a40 ffff88810588c200 ffffea00048ffa10 ffff888105889488
    raw: ffff88812383f588 0000000000150006 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff888123839d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888123839e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff888123839e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                            ^
     ffff888123839f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888123839f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 36eca8948323 ("block, bfq: add Early Queue Merge (EQM)")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: fix procress reference leakage for bfqq in merge chain [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 9 21:41:49 2024 +0800

    block, bfq: fix procress reference leakage for bfqq in merge chain
    
    [ Upstream commit 73aeab373557fa6ee4ae0b742c6211ccd9859280 ]
    
    Original state:
    
            Process 1       Process 2       Process 3       Process 4
             (BIC1)          (BIC2)          (BIC3)          (BIC4)
              Λ                |               |               |
               \--------------\ \-------------\ \-------------\|
                               V               V               V
              bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
        ref    0               1               2               4
    
    After commit 0e456dba86c7 ("block, bfq: choose the last bfqq from merge
    chain in bfq_setup_cooperator()"), if P1 issues a new IO:
    
    Without the patch:
    
            Process 1       Process 2       Process 3       Process 4
             (BIC1)          (BIC2)          (BIC3)          (BIC4)
              Λ                |               |               |
               \------------------------------\ \-------------\|
                                               V               V
              bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
        ref    0               0               2               4
    
    bfqq3 will be used to handle IO from P1, this is not expected, IO
    should be redirected to bfqq4;
    
    With the patch:
    
              -------------------------------------------
              |                                         |
            Process 1       Process 2       Process 3   |   Process 4
             (BIC1)          (BIC2)          (BIC3)     |    (BIC4)
                               |               |        |      |
                                \-------------\ \-------------\|
                                               V               V
              bfqq1--------->bfqq2---------->bfqq3----------->bfqq4
        ref    0               0               2               4
    
    IO is redirected to bfqq4, however, procress reference of bfqq3 is still
    2, while there is only P2 using it.
    
    Fix the problem by calling bfq_merge_bfqqs() for each bfqq in the merge
    chain. Also change bfqq_merge_bfqqs() to return new_bfqq to simplify
    code.
    
    Fixes: 0e456dba86c7 ("block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block, bfq: fix uaf for accessing waker_bfqq after splitting [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Mon Sep 9 21:41:48 2024 +0800

    block, bfq: fix uaf for accessing waker_bfqq after splitting
    
    [ Upstream commit 1ba0403ac6447f2d63914fb760c44a3b19c44eaf ]
    
    After commit 42c306ed7233 ("block, bfq: don't break merge chain in
    bfq_split_bfqq()"), if the current procress is the last holder of bfqq,
    the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and
    then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq
    may in the merge chain of bfqq, hence just recored waker_bfqq is still
    not safe.
    
    Fix the problem by adding a helper bfq_waker_bfqq() to check if
    bfqq->waker_bfqq is in the merge chain, and current procress is the only
    holder.
    
    Fixes: 42c306ed7233 ("block, bfq: don't break merge chain in bfq_split_bfqq()")
    Signed-off-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block: fix potential invalid pointer dereference in blk_add_partition [+ + +]
Author: Riyan Dhiman <[email protected]>
Date:   Wed Sep 11 18:59:54 2024 +0530

    block: fix potential invalid pointer dereference in blk_add_partition
    
    [ Upstream commit 26e197b7f9240a4ac301dd0ad520c0c697c2ea7d ]
    
    The blk_add_partition() function initially used a single if-condition
    (IS_ERR(part)) to check for errors when adding a partition. This was
    modified to handle the specific case of -ENXIO separately, allowing the
    function to proceed without logging the error in this case. However,
    this change unintentionally left a path where md_autodetect_dev()
    could be called without confirming that part is a valid pointer.
    
    This commit separates the error handling logic by splitting the
    initial if-condition, improving code readability and handling specific
    error scenarios explicitly. The function now distinguishes the general
    error case from -ENXIO without altering the existing behavior of
    md_autodetect_dev() calls.
    
    Fixes: b72053072c0b (block: allow partitions on host aware zone devices)
    Signed-off-by: Riyan Dhiman <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

block: print symbolic error name instead of error code [+ + +]
Author: Christian Heusel <[email protected]>
Date:   Fri Jan 12 00:15:18 2024 +0100

    block: print symbolic error name instead of error code
    
    [ Upstream commit 25c1772a0493463408489b1fae65cf77fe46cac1 ]
    
    Utilize the %pe print specifier to get the symbolic error name as a
    string (i.e "-ENOMEM") in the log message instead of the error code to
    increase its readablility.
    
    This change was suggested in
    https://lore.kernel.org/all/[email protected]/
    
    Signed-off-by: Christian Heusel <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Stable-dep-of: 26e197b7f924 ("block: fix potential invalid pointer dereference in blk_add_partition")
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: btusb: Fix not handling ZPL/short-transfer [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Sep 9 16:51:52 2024 -0400

    Bluetooth: btusb: Fix not handling ZPL/short-transfer
    
    [ Upstream commit 7b05933340f4490ef5b09e84d644d12484b05fdf ]
    
    Requesting transfers of the exact same size of wMaxPacketSize may result
    in ZPL/short-transfer since the USB stack cannot handle it as we are
    limiting the buffer size to be the same as wMaxPacketSize.
    
    Also, in terms of throughput this change has the same effect to
    interrupt endpoint as 290ba200815f "Bluetooth: Improve USB driver throughput
    by increasing the frame size" had for the bulk endpoint, so users of the
    advertisement bearer (e.g. BT Mesh) may benefit from this change.
    
    Fixes: 5e23b923da03 ("[Bluetooth] Add generic driver for Bluetooth USB devices")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Tested-by: Kiran K <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Aug 30 17:29:27 2024 -0400

    Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED
    
    [ Upstream commit d47da6bd4cfa982fe903f33423b9e2ec541e9496 ]
    
    If HCI_CONN_MGMT_CONNECTED has been set then the event shall be
    HCI_CONN_MGMT_DISCONNECTED.
    
    Fixes: b644ba336997 ("Bluetooth: Update device_connected and device_found events to latest API")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Aug 16 12:05:00 2023 -0700

    Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL
    
    [ Upstream commit cfbfeee61582e638770a1a10deef866c9adb38f5 ]
    
    This ignores errors from HCI_OP_REMOTE_NAME_REQ_CANCEL since it
    shouldn't interfere with the stopping of discovery and in certain
    conditions it seems to be failing.
    
    Link: https://github.com/bluez/bluez/issues/575
    Fixes: d0b137062b2d ("Bluetooth: hci_sync: Rework init stages")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() [+ + +]
Author: Jiwon Kim <[email protected]>
Date:   Wed Sep 18 14:06:02 2024 +0000

    bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()
    
    [ Upstream commit 0cbfd45fbcf0cb26d85c981b91c62fe73cdee01c ]
    
    syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce
    this[1], one bond device (bond1) has xdpdrv, which increases
    bpf_master_redirect_enabled_key. Another bond device (bond0) which is
    unsupported by XDP but its slave (veth3) has xdpgeneric that returns
    XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect().
    To reduce unnecessary warnings and improve log management, we need to
    delete the WARN_ON_ONCE() and add ratelimit to the netdev_err().
    
    [1] Steps to reproduce:
        # Needs tx_xdp with return XDP_TX;
        ip l add veth0 type veth peer veth1
        ip l add veth3 type veth peer veth4
        ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP
        ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default
        ip l set veth0 master bond1
        ip l set bond1 up
        # Increases bpf_master_redirect_enabled_key
        ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx
        ip l set veth3 master bond0
        ip l set bond0 up
        ip l set veth4 up
        # Triggers WARN_ON_ONCE() from the xdp_master_redirect()
        ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=c187823a52ed505b2257
    Fixes: 9e2ee5c7e7c3 ("net, bonding: Add XDP support to the bonding driver")
    Signed-off-by: Jiwon Kim <[email protected]>
    Signed-off-by: Nikolay Aleksandrov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos [+ + +]
Author: Eduard Zingerman <[email protected]>
Date:   Thu Aug 22 01:01:23 2024 -0700

    bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos
    
    [ Upstream commit 3d2786d65aaa954ebd3fcc033ada433e10da21c4 ]
    
    In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL
    referencing a non-existing BTF type, function bpf_core_calc_relo_insn
    would cause a null pointer deference.
    
    Fix this by adding a proper check upper in call stack, as malformed
    relocation records could be passed from user space.
    
    Simplest reproducer is a program:
    
        r0 = 0
        exit
    
    With a single relocation record:
    
        .insn_off = 0,          /* patch first instruction */
        .type_id = 100500,      /* this type id does not exist */
        .access_str_off = 6,    /* offset of string "0" */
        .kind = BPF_CORE_TYPE_ID_LOCAL,
    
    See the link for original reproducer or next commit for a test case.
    
    Fixes: 74753e1462e7 ("libbpf: Replace btf__type_by_id() with btf_type_by_id().")
    Reported-by: Liu RuiTong <[email protected]>
    Closes: https://lore.kernel.org/bpf/CAK55_s6do7C+DVwbwY_7nKfUz0YLDoiA1v6X3Y9+p0sWzipFSA@mail.gmail.com/
    Acked-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Disable some `attribute ignored' warnings in GCC [+ + +]
Author: Jose E. Marchesi <[email protected]>
Date:   Tue May 7 09:42:27 2024 +0200

    bpf: Disable some `attribute ignored' warnings in GCC
    
    [ Upstream commit b0fbdf759da05a35b67fd27b8859738b79af25d6 ]
    
    This patch modifies selftests/bpf/Makefile to pass -Wno-attributes to
    GCC.  This is because of the following attributes which are ignored:
    
    - btf_decl_tag
    - btf_type_tag
    
      There are many of these.  At the moment none of these are
      recognized/handled by gcc-bpf.
    
      We are aware that btf_decl_tag is necessary for some of the
      selftest harness to communicate test failure/success.  Support for
      it is in progress in GCC upstream:
    
      https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650482.html
    
      However, the GCC master branch is not yet open, so the series
      above (currently under review upstream) wont be able to make it
      there until 14.1 gets released, probably mid next week.
    
      As for btf_type_tag, more extensive work will be needed in GCC
      upstream to support it in both BTF and DWARF.  We have a WIP big
      patch for that, but that is not needed to compile/build the
      selftests.
    
    - used
    
      There are SEC macros defined in the selftests as:
    
      #define SEC(N) __attribute__((section(N),used))
    
      The SEC macro is used for both functions and global variables.
      According to the GCC documentation `used' attribute is really only
      meaningful for functions, and it warns when the attribute is used
      for other global objects, like for example ctl_array in
      test_xdp_noinline.c.
    
      Ignoring this is benign.
    
    - align_value
    
      In progs/test_cls_redirect.c:127 there is:
    
      typedef uint8_t *net_ptr __attribute__((align_value(8)));
    
      GCC warns that it is ignoring this attribute, because it is not
      implemented by GCC.
    
      I think ignoring this attribute in GCC is benign, because according
      to the clang documentation [1] its purpose seems to be merely
      declarative and doesn't seem to translate into extra checks at
      run-time, only to perhaps better optimized code ("runtime behavior
      is undefined if the pointed memory object is not aligned to the
      specified alignment").
    
      [1] https://clang.llvm.org/docs/AttributeReference.html#align-value
    
    Tested in bpf-next master.
    
    Signed-off-by: Jose E. Marchesi <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 3ece93a4087b ("selftests/bpf: Fix wrong binary in Makefile log output")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 13 21:17:46 2024 +0200

    bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit
    
    [ Upstream commit cfe69c50b05510b24e26ccb427c7cc70beafd6c1 ]
    
    The bpf_strtol() and bpf_strtoul() helpers are currently broken on 32bit:
    
    The argument type ARG_PTR_TO_LONG is BPF-side "long", not kernel-side "long"
    and therefore always considered fixed 64bit no matter if 64 or 32bit underlying
    architecture.
    
    This contract breaks in case of the two mentioned helpers since their BPF_CALL
    definition for the helpers was added with {unsigned,}long *res. Meaning, the
    transition from BPF-side "long" (BPF program) to kernel-side "long" (BPF helper)
    breaks here.
    
    Both helpers call __bpf_strtoll() with "long long" correctly, but later assigning
    the result into 32-bit "*(long *)" on 32bit architectures. From a BPF program
    point of view, this means upper bits will be seen as uninitialised.
    
    Therefore, fix both BPF_CALL signatures to {s,u}64 types to fix this situation.
    
    Now, changing also uapi/bpf.h helper documentation which generates bpf_helper_defs.h
    for BPF programs is tricky: Changing signatures there to __{s,u}64 would trigger
    compiler warnings (incompatible pointer types passing 'long *' to parameter of type
    '__s64 *' (aka 'long long *')) for existing BPF programs.
    
    Leaving the signatures as-is would be fine as from BPF program point of view it is
    still BPF-side "long" and thus equivalent to __{s,u}64 on 64 or 32bit underlying
    architectures.
    
    Note that bpf_strtol() and bpf_strtoul() are the only helpers with this issue.
    
    Fixes: d7a4cb9b6705 ("bpf: Introduce bpf_strtol and bpf_strtoul helpers")
    Reported-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix helper writes to read-only maps [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 13 21:17:48 2024 +0200

    bpf: Fix helper writes to read-only maps
    
    [ Upstream commit 32556ce93bc45c730829083cb60f95a2728ea48b ]
    
    Lonial found an issue that despite user- and BPF-side frozen BPF map
    (like in case of .rodata), it was still possible to write into it from
    a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
    as arguments.
    
    In check_func_arg() when the argument is as mentioned, the meta->raw_mode
    is never set. Later, check_helper_mem_access(), under the case of
    PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
    subsequent call to check_map_access_type() and given the BPF map is
    read-only it succeeds.
    
    The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
    when results are written into them as opposed to read out of them. The
    latter indicates that it's okay to pass a pointer to uninitialized memory
    as the memory is written to anyway.
    
    However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
    just with additional alignment requirement. So it is better to just get
    rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
    fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
    alignment given these helpers write directly into the args via *<ptr> = val.
    The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>).
    
    MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
    argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
    the buffer size a priori and therefore cannot blindly write *<ptr> = val.
    
    Fixes: 57c3bb725a3d ("bpf: Introduce ARG_PTR_TO_{INT,LONG} arg types")
    Reported-by: Lonial Con <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Acked-by: Shung-Hsi Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() [+ + +]
Author: Oleg Nesterov <[email protected]>
Date:   Thu Sep 19 15:28:53 2024 +0200

    bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()
    
    commit 5fe6e308abaea082c20fbf2aa5df8e14495622cf upstream.
    
    If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the
    error_free label and frees the array of bpf_uprobe's without calling
    bpf_uprobe_unregister().
    
    This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer
    without removing it from the uprobe->consumers list.
    
    Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link")
    Closes: https://lore.kernel.org/all/[email protected]/
    Reported-by: [email protected]
    Signed-off-by: Oleg Nesterov <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Tested-by: [email protected]
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 13 21:17:49 2024 +0200

    bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types
    
    [ Upstream commit 18752d73c1898fd001569195ba4b0b8c43255f4a ]
    
    When checking malformed helper function signatures, also take other argument
    types into account aside from just ARG_PTR_TO_UNINIT_MEM.
    
    This concerns (formerly) ARG_PTR_TO_{INT,LONG} given uninitialized memory can
    be passed there, too.
    
    The func proto sanity check goes back to commit 435faee1aae9 ("bpf, verifier:
    add ARG_PTR_TO_RAW_STACK type"), and its purpose was to detect wrong func protos
    which had more than just one MEM_UNINIT-tagged type as arguments.
    
    The reason more than one is currently not supported is as we mark stack slots with
    STACK_MISC in check_helper_call() in case of raw mode based on meta.access_size to
    allow uninitialized stack memory to be passed to helpers when they just write into
    the buffer.
    
    Probing for base type as well as MEM_UNINIT tagging ensures that other types do not
    get missed (as it used to be the case for ARG_PTR_TO_{INT,LONG}).
    
    Fixes: 57c3bb725a3d ("bpf: Introduce ARG_PTR_TO_{INT,LONG} arg types")
    Reported-by: Shung-Hsi Yu <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Andrii Nakryiko <[email protected]>
    Acked-by: Shung-Hsi Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0 [+ + +]
Author: Song Liu <[email protected]>
Date:   Tue Sep 10 22:55:08 2024 -0700

    bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0
    
    commit 300a90b2cb5d442879e6398920c49aebbd5c8e40 upstream.
    
    bpf task local storage is now using task_struct->bpf_storage, so
    bpf_lsm_blob_sizes.lbs_task is no longer needed. Remove it to save some
    memory.
    
    Fixes: a10787e6d58c ("bpf: Enable task local storage for tracing programs")
    Cc: [email protected]
    Cc: KP Singh <[email protected]>
    Cc: Matt Bobrowski <[email protected]>
    Signed-off-by: Song Liu <[email protected]>
    Acked-by: Matt Bobrowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bpf: Temporarily define BPF_NO_PRESEVE_ACCESS_INDEX for GCC [+ + +]
Author: Jose E. Marchesi <[email protected]>
Date:   Tue May 7 11:50:11 2024 +0200

    bpf: Temporarily define BPF_NO_PRESEVE_ACCESS_INDEX for GCC
    
    [ Upstream commit 675b4e24bc50f4600b6bf3527fdbaa1f73498334 ]
    
    The vmlinux.h file generated by bpftool makes use of compiler pragmas
    in order to install the CO-RE preserve_access_index in all the struct
    types derived from the BTF info:
    
      #ifndef __VMLINUX_H__
      #define __VMLINUX_H__
    
      #ifndef BPF_NO_PRESERVE_ACCESS_INDEX
      #pragma clang attribute push (__attribute__((preserve_access_index)), apply_t = record
      #endif
    
      [... type definitions generated from kernel BTF ... ]
    
      #ifndef BPF_NO_PRESERVE_ACCESS_INDEX
      #pragma clang attribute pop
      #endif
    
    The `clang attribute push/pop' pragmas are specific to clang/llvm and
    are not supported by GCC.
    
    At the moment the BTF dumping services in libbpf do not support
    dicriminating between types dumped because they are directly referred
    and types dumped because they are dependencies.  A suitable API is
    being worked now. See [1] and [2].
    
    In the interim, this patch changes the selftests/bpf Makefile so it
    passes -DBPF_NO_PRESERVE_ACCESS_INDEX to GCC when it builds the
    selftests.  This workaround is temporary, and may have an impact on
    the results of the GCC-built tests.
    
    [1] https://lore.kernel.org/bpf/[email protected]/T/#u
    [2] https://lore.kernel.org/bpf/[email protected]/T/#u
    
    Tested in bpf-next master.
    No regressions.
    
    Signed-off-by: Jose E. Marchesi <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 3ece93a4087b ("selftests/bpf: Fix wrong binary in Makefile log output")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Use -Wno-error in certain tests when building with GCC [+ + +]
Author: Jose E. Marchesi <[email protected]>
Date:   Sat Jan 27 11:07:02 2024 +0100

    bpf: Use -Wno-error in certain tests when building with GCC
    
    [ Upstream commit 646751d523587cfd7ebcf1733298ecd470879eda ]
    
    Certain BPF selftests contain code that, albeit being legal C, trigger
    warnings in GCC that cannot be disabled.  This is the case for example
    for the tests
    
      progs/btf_dump_test_case_bitfields.c
      progs/btf_dump_test_case_namespacing.c
      progs/btf_dump_test_case_packing.c
      progs/btf_dump_test_case_padding.c
      progs/btf_dump_test_case_syntax.c
    
    which contain struct type declarations inside function parameter
    lists.  This is problematic, because:
    
    - The BPF selftests are built with -Werror.
    
    - The Clang and GCC compilers sometimes differ when it comes to handle
      warnings.  in the handling of warnings.  One compiler may emit
      warnings for code that the other compiles compiles silently, and one
      compiler may offer the possibility to disable certain warnings, while
      the other doesn't.
    
    In order to overcome this problem, this patch modifies the
    tools/testing/selftests/bpf/Makefile in order to:
    
    1. Enable the possibility of specifing per-source-file extra CFLAGS.
       This is done by defining a make variable like:
    
       <source-filename>-CFLAGS := <whateverflags>
    
       And then modifying the proper Make rule in order to use these flags
       when compiling <source-filename>.
    
    2. Use the mechanism above to add -Wno-error to CFLAGS for the
       following selftests:
    
       progs/btf_dump_test_case_bitfields.c
       progs/btf_dump_test_case_namespacing.c
       progs/btf_dump_test_case_packing.c
       progs/btf_dump_test_case_padding.c
       progs/btf_dump_test_case_syntax.c
    
       Note the corresponding -CFLAGS variables for these files are
       defined only if the selftests are being built with GCC.
    
    Note that, while compiler pragmas can generally be used to disable
    particular warnings per file, this 1) is only possible for warning
    that actually can be disabled in the command line, i.e. that have
    -Wno-FOO options, and 2) doesn't apply to -Wno-error.
    
    Tested in bpf-next master branch.
    No regressions.
    
    Signed-off-by: Jose E. Marchesi <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 3ece93a4087b ("selftests/bpf: Fix wrong binary in Makefile log output")
    Signed-off-by: Sasha Levin <[email protected]>

bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error [+ + +]
Author: Daniel Borkmann <[email protected]>
Date:   Fri Sep 13 21:17:50 2024 +0200

    bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
    
    [ Upstream commit 4b3786a6c5397dc220b1483d8e2f4867743e966f ]
    
    For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input
    arguments, zero the value for the case of an error as otherwise it could leak
    memory. For tracing, it is not needed given CAP_PERFMON can already read all
    kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped
    in here.
    
    Also, the MTU helpers mtu_len pointer value is being written but also read.
    Technically, the MEM_UNINIT should not be there in order to always force init.
    Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now
    implies two things actually: i) write into memory, ii) memory does not have
    to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,
    ii) memory must be initialized. This means that for bpf_*_check_mtu() we're
    readding the issue we're trying to fix, that is, it would then be able to
    write back into things like .rodata BPF maps. Follow-up work will rework the
    MEM_UNINIT semantics such that the intent can be better expressed. For now
    just clear the *mtu_len on error path which can be lifted later again.
    
    Fixes: 8a67f2de9b1d ("bpf: expose bpf_strtol and bpf_strtoul to all program types")
    Fixes: d7a4cb9b6705 ("bpf: Introduce bpf_strtol and bpf_strtoul helpers")
    Signed-off-by: Daniel Borkmann <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: always update fstrim_range on failure in FITRIM ioctl [+ + +]
Author: Luca Stefani <[email protected]>
Date:   Mon Sep 2 13:10:53 2024 +0200

    btrfs: always update fstrim_range on failure in FITRIM ioctl
    
    commit 3368597206dc3c6c3c2247ee146beada14c67380 upstream.
    
    Even in case of failure we could've discarded some data and userspace
    should be made aware of it, so copy fstrim_range to userspace
    regardless.
    
    Also make sure to update the trimmed bytes amount even if
    btrfs_trim_free_extents fails.
    
    CC: [email protected] # 5.15+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Luca Stefani <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix race setting file private on concurrent lseek using same fd [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Sep 3 10:55:36 2024 +0100

    btrfs: fix race setting file private on concurrent lseek using same fd
    
    [ Upstream commit 7ee85f5515e86a4e2a2f51969795920733912bad ]
    
    When doing concurrent lseek(2) system calls against the same file
    descriptor, using multiple threads belonging to the same process, we have
    a short time window where a race happens and can result in a memory leak.
    
    The race happens like this:
    
    1) A program opens a file descriptor for a file and then spawns two
       threads (with the pthreads library for example), lets call them
       task A and task B;
    
    2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at
       file.c:find_desired_extent() while holding a read lock on the inode;
    
    3) At the start of find_desired_extent(), it extracts the file's
       private_data pointer into a local variable named 'private', which has
       a value of NULL;
    
    4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode
       in shared mode and enters file.c:find_desired_extent(), where it also
       extracts file->private_data into its local variable 'private', which
       has a NULL value;
    
    5) Because it saw a NULL file private, task A allocates a private
       structure and assigns to the file structure;
    
    6) Task B also saw a NULL file private so it also allocates its own file
       private and then assigns it to the same file structure, since both
       tasks are using the same file descriptor.
    
       At this point we leak the private structure allocated by task A.
    
    Besides the memory leak, there's also the detail that both tasks end up
    using the same cached state record in the private structure (struct
    btrfs_file_private::llseek_cached_state), which can result in a
    use-after-free problem since one task can free it while the other is
    still using it (only one task took a reference count on it). Also, sharing
    the cached state is not a good idea since it could result in incorrect
    results in the future - right now it should not be a problem because it
    end ups being used only in extent-io-tree.c:count_range_bits() where we do
    range validation before using the cached state.
    
    Fix this by protecting the private assignment and check of a file while
    holding the inode's spinlock and keep track of the task that allocated
    the private, so that it's used only by that task in order to prevent
    user-after-free issues with the cached state record as well as potentially
    using it incorrectly in the future.
    
    Fixes: 3c32c7212f16 ("btrfs: use cached state when looking for delalloc ranges with lseek")
    CC: [email protected] # 6.6+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: reorder btrfs_inode to fill gaps [+ + +]
Author: David Sterba <[email protected]>
Date:   Wed Sep 27 21:04:32 2023 +0200

    btrfs: reorder btrfs_inode to fill gaps
    
    [ Upstream commit 398fb9131f31bd25aa187613c9942f4232e952b7 ]
    
    Previous commit created a hole in struct btrfs_inode, we can move
    outstanding_extents there. This reduces size by 8 bytes from 1120 to
    1112 on a release config.
    
    Signed-off-by: David Sterba <[email protected]>
    Stable-dep-of: 7ee85f5515e8 ("btrfs: fix race setting file private on concurrent lseek using same fd")
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: subpage: fix the bitmap dump which can cause bitmap corruption [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Fri Aug 30 16:35:48 2024 +0930

    btrfs: subpage: fix the bitmap dump which can cause bitmap corruption
    
    [ Upstream commit 77b0b98bb743f5d04d8f995ba1936e1143689d4a ]
    
    In commit 75258f20fb70 ("btrfs: subpage: dump extra subpage bitmaps for
    debug") an internal macro GET_SUBPAGE_BITMAP() is introduced to grab the
    bitmap of each attribute.
    
    But that commit is using bitmap_cut() which will do the left shift of
    the larger bitmap, causing incorrect values.
    
    Thankfully this bitmap_cut() is only called for debug usage, and so far
    it's not yet causing problem.
    
    Fix it to use bitmap_read() to only grab the desired sub-bitmap.
    
    Fixes: 75258f20fb70 ("btrfs: subpage: dump extra subpage bitmaps for debug")
    CC: [email protected] # 6.6+
    Signed-off-by: Qu Wenruo <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: tree-checker: fix the wrong output of data backref objectid [+ + +]
Author: Qu Wenruo <[email protected]>
Date:   Wed Sep 11 07:06:45 2024 +0930

    btrfs: tree-checker: fix the wrong output of data backref objectid
    
    commit b0b595e61d97de61c15b379b754b2caa90e83e5c upstream.
    
    [BUG]
    There are some reports about invalid data backref objectids, the report
    looks like this:
    
      BTRFS critical (device sda): corrupt leaf: block=333654787489792 slot=110 extent bytenr=333413935558656 len=65536 invalid data ref objectid value 2543
    
    The data ref objectid is the inode number inside the subvolume.
    
    But in above case, the value is completely sane, not really showing the
    problem.
    
    [CAUSE]
    The root cause of the problem is the deprecated feature, inode cache.
    
    This feature results a special inode number, -12ULL, and it's no longer
    recognized by tree-checker, triggering the error.
    
    The direct problem here is the output of data ref objectid. The value
    shown is in fact the dref_root (subvolume id), not the dref_objectid
    (inode number).
    
    [FIX]
    Fix the output to use dref_objectid instead.
    
    Reported-by: Neil Parton <[email protected]>
    Reported-by: Archange <[email protected]>
    Link: https://lore.kernel.org/linux-btrfs/CAAYHqBbrrgmh6UmW3ANbysJX9qG9Pbg3ZwnKsV=5mOpv_qix_Q@mail.gmail.com/
    Link: https://lore.kernel.org/linux-btrfs/[email protected]/
    Fixes: f333a3c7e832 ("btrfs: tree-checker: validate dref root and objectid")
    CC: [email protected] # 6.11
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Qu Wenruo <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: update comment for struct btrfs_inode::lock [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed Oct 4 11:38:53 2023 +0100

    btrfs: update comment for struct btrfs_inode::lock
    
    [ Upstream commit 68539bd0e73b457f88a9d00cabb6533ec8582dc9 ]
    
    Update the comment for the lock named "lock" in struct btrfs_inode because
    it does not mention that the fields "delalloc_bytes", "defrag_bytes",
    "csum_bytes", "outstanding_extents" and "disk_i_size" are also protected
    by that lock.
    
    Also add a comment on top of each field protected by this lock to mention
    that the lock protects them.
    
    Signed-off-by: Filipe Manana <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Stable-dep-of: 7ee85f5515e8 ("btrfs: fix race setting file private on concurrent lseek using same fd")
    Signed-off-by: Sasha Levin <[email protected]>

 
bus: integrator-lm: fix OF node leak in probe() [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Aug 26 07:49:34 2024 +0200

    bus: integrator-lm: fix OF node leak in probe()
    
    commit 15a62b81175885b5adfcaf49870466e3603f06c7 upstream.
    
    Driver code is leaking OF node reference from of_find_matching_node() in
    probe().
    
    Fixes: ccea5e8a5918 ("bus: Add driver for Integrator/AP logic modules")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Acked-by: Liviu Dudau <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

bus: mhi: host: pci_generic: Fix the name for the Telit FE990A [+ + +]
Author: Fabio Porcedda <[email protected]>
Date:   Tue Aug 20 10:04:39 2024 +0200

    bus: mhi: host: pci_generic: Fix the name for the Telit FE990A
    
    commit bfc5ca0fd1ea7aceae0b682fa4bd8079c52f96c8 upstream.
    
    Add a mhi_pci_dev_info struct specific for the Telit FE990A modem in
    order to use the correct product name.
    
    Cc: [email protected] # 6.1+
    Fixes: 0724869ede9c ("bus: mhi: host: pci_generic: add support for Telit FE990 modem")
    Signed-off-by: Fabio Porcedda <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
cachefiles: Fix non-taking of sb_writers around set/removexattr [+ + +]
Author: David Howells <[email protected]>
Date:   Tue Jul 23 15:35:29 2024 +0100

    cachefiles: Fix non-taking of sb_writers around set/removexattr
    
    [ Upstream commit 80887f31672970abae3aaa9cf62ac72a124e7c89 ]
    
    Unlike other vfs_xxxx() calls, vfs_setxattr() and vfs_removexattr() don't
    take the sb_writers lock, so the caller should do it for them.
    
    Fix cachefiles to do this.
    
    Fixes: 9ae326a69004 ("CacheFiles: A cache that backs onto a mounted filesystem")
    Signed-off-by: David Howells <[email protected]>
    cc: Christian Brauner <[email protected]>
    cc: Gao Xiang <[email protected]>
    cc: [email protected]
    cc: [email protected]
    cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]/ # v2
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Sep 4 18:22:37 2024 -0700

    can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().
    
    [ Upstream commit 94b0818fa63555a65f6ba107080659ea6bcca63e ]
    
    syzbot reported a warning in bcm_release(). [0]
    
    The blamed change fixed another warning that is triggered when
    connect() is issued again for a socket whose connect()ed device has
    been unregistered.
    
    However, if the socket is just close()d without the 2nd connect(), the
    remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry()
    in bcm_release().
    
    Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify().
    
    [0]
    name '4986'
    WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
    Modules linked in:
    CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
    Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07
    RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246
    RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a
    R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640
    R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000
    FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     bcm_release+0x250/0x880 net/can/bcm.c:1578
     __sock_release net/socket.c:659 [inline]
     sock_close+0xbc/0x240 net/socket.c:1421
     __fput+0x24a/0x8a0 fs/file_table.c:422
     task_work_run+0x24f/0x310 kernel/task_work.c:228
     exit_task_work include/linux/task_work.h:40 [inline]
     do_exit+0xa2f/0x27f0 kernel/exit.c:882
     do_group_exit+0x207/0x2c0 kernel/exit.c:1031
     __do_sys_exit_group kernel/exit.c:1042 [inline]
     __se_sys_exit_group kernel/exit.c:1040 [inline]
     __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
     x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fcfb51ee969
    Code: Unable to access opcode bytes at 0x7fcfb51ee93f.
    RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969
    RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
    RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000
    R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0
    R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160
     </TASK>
    
    Fixes: 76fe372ccb81 ("can: bcm: Remove proc entry when dev is unregistered.")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=0532ac7a06fb1a03187e
    Tested-by: [email protected]
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Reviewed-by: Vincent Mailhol <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD [+ + +]
Author: Stefan Mätje <[email protected]>
Date:   Thu Sep 5 00:27:40 2024 +0200

    can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD
    
    commit 75b3189540578f96b4996e4849b6649998f49455 upstream.
    
    Remove the CAN_CTRLMODE_3_SAMPLES announcement for CAN-USB/3-FD devices
    because these devices don't support it.
    
    The hardware has a Microchip SAM E70 microcontroller that uses a Bosch
    MCAN IP core as CAN FD controller. But this MCAN core doesn't support
    triple sampling.
    
    Fixes: 80662d943075 ("can: esd_usb: Add support for esd CAN-USB/3")
    Cc: [email protected]
    Signed-off-by: Stefan Mätje <[email protected]>
    Reviewed-by: Vincent Mailhol <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

can: j1939: use correct function name in comment [+ + +]
Author: Zhang Changzhong <[email protected]>
Date:   Thu Aug 29 20:48:23 2024 +0800

    can: j1939: use correct function name in comment
    
    [ Upstream commit dc2ddcd136fe9b6196a7dd01f75f824beb02d43f ]
    
    The function j1939_cancel_all_active_sessions() was renamed to
    j1939_cancel_active_session() but name in comment wasn't updated.
    
    Signed-off-by: Zhang Changzhong <[email protected]>
    Acked-by: Oleksij Rempel <[email protected]>
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: m_can: enable NAPI before enabling interrupts [+ + +]
Author: Jake Hamby <[email protected]>
Date:   Fri Sep 6 23:19:51 2024 +0000

    can: m_can: enable NAPI before enabling interrupts
    
    [ Upstream commit 801ad2f87b0c6d0c34a75a4efd6bfd3a2d9f9298 ]
    
    If an interrupt (RX-complete or error flag) is set when bringing up
    the CAN device, e.g. due to CAN bus traffic before initializing the
    device, when m_can_start() is called and interrupts are enabled,
    m_can_isr() is called immediately, which disables all CAN interrupts
    and calls napi_schedule().
    
    Because napi_enable() isn't called until later in m_can_open(), the
    call to napi_schedule() never schedules the m_can_poll() callback and
    the device is left with interrupts disabled and can't receive any CAN
    packets until rebooted.
    
    This can be verified by running "cansend" from another device before
    setting the bitrate and calling "ip link set up can0" on the test
    device. Adding debug lines to m_can_isr() shows it's called with flags
    (IR_EP | IR_EW | IR_CRCE), which calls m_can_disable_all_interrupts()
    and napi_schedule(), and then m_can_poll() is never called.
    
    Move the call to napi_enable() above the call to m_can_start() to
    enable any initial interrupt flags to be handled by m_can_poll() so
    that interrupts are reenabled. Add a call to napi_disable() in the
    error handling section of m_can_open(), to handle the case where later
    functions return errors.
    
    Also, in m_can_close(), move the call to napi_disable() below the call
    to m_can_stop() to ensure all interrupts are handled when bringing
    down the device. This race condition is much less likely to occur.
    
    Tested on a Microchip SAMA7G54 MPU. The fix should be applicable to
    any SoC with a Bosch M_CAN controller.
    
    Signed-off-by: Jake Hamby <[email protected]>
    Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: m_can: m_can_close(): stop clocks after device has been shut down [+ + +]
Author: Marc Kleine-Budde <[email protected]>
Date:   Mon Sep 9 15:07:41 2024 +0200

    can: m_can: m_can_close(): stop clocks after device has been shut down
    
    [ Upstream commit 2c09b50efcad985cf920ca88baa9aa52b1999dcc ]
    
    After calling m_can_stop() an interrupt may be pending or NAPI might
    still be executed. This means the driver might still touch registers
    of the IP core after the clocks have been disabled. This is not good
    practice and might lead to aborts depending on the SoC integration.
    
    To avoid these potential problems, make m_can_close() symmetric to
    m_can_open(), i.e. stop the clocks at the end, right before shutting
    down the transceiver.
    
    Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Sun Jul 14 17:13:15 2024 +0300

    clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs
    
    [ Upstream commit 2d6e9ee7cb3e79b1713783c633b13af9aeffc90c ]
    
    The maximum number of PLL components on SAMA7G5 is 3 (one fractional
    part and 2 dividers). Allocate the needed amount of memory for
    sama7g5_plls 2d array. Previous code used to allocate 7 array entries for
    each PLL. While at it, replace 3 with PLL_COMPID_MAX in the loop which
    parses the sama7g5_plls 2d array.
    
    Fixes: cb783bbbcf54 ("clk: at91: sama7g5: add clock support for sama7g5")
    Acked-by: Stephen Boyd <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Claudiu Beznea <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll [+ + +]
Author: Shengjiu Wang <[email protected]>
Date:   Fri Jun 14 15:42:03 2024 +0800

    clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll
    
    [ Upstream commit d40371a1c963db688b37826adaf5ffdafb0862a1 ]
    
    According to Reference Manual of i.MX8MP
    The parent clock of "earc_phy" is "sai_pll_out_div2",
    The parent clock of "audpll" is "osc_24m".
    
    Add CLK_GATE_PARENT() macro for usage of specifying parent clock.
    
    Fixes: 6cd95f7b151c ("clk: imx: imx8mp: Add audiomix block control")
    Signed-off-by: Shengjiu Wang <[email protected]>
    Reviewed-by: Peng Fan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: composite-7ulp: Check the PCC present bit [+ + +]
Author: Ye Li <[email protected]>
Date:   Fri Jun 7 21:33:35 2024 +0800

    clk: imx: composite-7ulp: Check the PCC present bit
    
    [ Upstream commit 4717ccadb51e2630790dddd222830702de17f090 ]
    
    When some module is disabled by fuse, its PCC PR bit is default 0 and
    PCC is not operational. Any write to this PCC will cause SError.
    
    Fixes: b40ba8065347 ("clk: imx: Update the compsite driver to support imx8ulp")
    Reviewed-by: Peng Fan <[email protected]>
    Signed-off-by: Ye Li <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: composite-8m: Enable gate clk with mcore_booted [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Jun 7 21:33:33 2024 +0800

    clk: imx: composite-8m: Enable gate clk with mcore_booted
    
    [ Upstream commit 8f32e9dd0916eb3fd4bcf550ed1d04542a65cb9e ]
    
    Bootloader might disable some CCM ROOT Slices. So if mcore_booted set with
    display CCM ROOT disabled by Bootloader, kernel display BLK CTRL driver
    imx8m_blk_ctrl_driver_init may hang the system because the BUS clk is
    disabled.
    
    Add back gate ops, but with disable doing nothing, then the CCM ROOT
    will be enabled when used.
    
    Fixes: bb7e897b002a ("clk: imx8m: check mcore_booted before register clk")
    Reviewed-by: Ye Li <[email protected]>
    Reviewed-by: Jacky Bai <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: composite-8m: Less function calls in __imx8m_clk_hw_composite() after error detection [+ + +]
Author: Markus Elfring <[email protected]>
Date:   Fri Dec 22 16:48:24 2023 +0100

    clk: imx: composite-8m: Less function calls in __imx8m_clk_hw_composite() after error detection
    
    [ Upstream commit fed6bf52c86df27ad4f39a72cdad8c27da9a50ba ]
    
    The function “kfree” was called in up to three cases
    by the function “__imx8m_clk_hw_composite” during error handling
    even if the passed variables contained a null pointer.
    
    Adjust jump targets according to the Linux coding style convention.
    
    Signed-off-by: Markus Elfring <[email protected]>
    Reviewed-by: Peng Fan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Stable-dep-of: 8f32e9dd0916 ("clk: imx: composite-8m: Enable gate clk with mcore_booted")
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: composite-93: keep root clock on when mcore enabled [+ + +]
Author: Jacky Bai <[email protected]>
Date:   Fri Jun 7 21:33:34 2024 +0800

    clk: imx: composite-93: keep root clock on when mcore enabled
    
    [ Upstream commit d342df11726bfac9c3a9d2037afa508ac0e9e44e ]
    
    Previously we assumed that the root clock slice is enabled
    by default when kernel boot up. But the bootloader may disable
    the clocks before jump into kernel. The gate ops should be registered
    rather than NULL to make sure the disabled clock can be enabled
    when kernel boot up.  Refine the code to skip disable the clock
    if mcore booted.
    
    Fixes: a740d7350ff7 ("clk: imx: imx93: add mcore_booted module paratemter")
    Signed-off-by: Jacky Bai <[email protected]>
    Reviewed-by: Peng Fan <[email protected]>
    Tested-by: Chancel Liu <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: fracn-gppll: fix fractional part of PLL getting lost [+ + +]
Author: Pengfei Li <[email protected]>
Date:   Fri Jun 7 21:33:36 2024 +0800

    clk: imx: fracn-gppll: fix fractional part of PLL getting lost
    
    [ Upstream commit 7622f888fca125ae46f695edf918798ebc0506c5 ]
    
    Fractional part of PLL gets lost after re-enabling the PLL. the
    MFN can NOT be automatically loaded when doing frac PLL enable/disable,
    So when re-enable PLL, configure mfn explicitly.
    
    Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll")
    Signed-off-by: Pengfei Li <[email protected]>
    Reviewed-by: Jacky Bai <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: imx6ul: fix default parent for enet*_ref_sel [+ + +]
Author: Sebastien Laveze <[email protected]>
Date:   Tue May 28 17:14:33 2024 +0200

    clk: imx: imx6ul: fix default parent for enet*_ref_sel
    
    [ Upstream commit e52fd71333b4ed78fd5bb43094bdc46476614d25 ]
    
    The clk_set_parent for "enet1_ref_sel" and  "enet2_ref_sel" are
    incorrect, therefore the original requirements to have "enet_clk_ref" as
    output sourced by iMX ENET PLL as a default config is not met.
    
    Only "enet[1,2]_ref_125m" "enet[1,2]_ref_pad" are possible parents for
    "enet1_ref_sel" and "enet2_ref_sel".
    
    This was observed as a regression using a custom device tree which was
    expecting this default config.
    
    This can be fixed at the device tree level but having a default config
    matching the original behavior (before refclock mux) will avoid breaking
    existing configs.
    
    Fixes: 4e197ee880c2 ("clk: imx6ul: add ethernet refclock mux support")
    Link: https://lore.kernel.org/lkml/20230306020226.GC143566@dragon/T/
    Signed-off-by: Sebastien Laveze <[email protected]>
    Reviewed-by: Oleksij Rempel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: imx8mp: fix clock tree update of TF-A managed clocks [+ + +]
Author: Zhipeng Wang <[email protected]>
Date:   Fri Jun 7 21:33:38 2024 +0800

    clk: imx: imx8mp: fix clock tree update of TF-A managed clocks
    
    [ Upstream commit 3d29036853b9cb07ac49e8261fca82a940be5c41 ]
    
    On the i.MX8M*, the TF-A exposes a SiP (Silicon Provider) service
    for DDR frequency scaling. The imx8m-ddrc-devfreq driver calls the
    SiP and then does clk_set_parent on the DDR muxes to synchronize
    the clock tree.
    
    since commit 936c383673b9 ("clk: imx: fix composite peripheral flags"),
    these TF-A managed muxes have SET_PARENT_GATE set, which results
    in imx8m-ddrc-devfreq's clk_set_parent after SiP failing with -EBUSY:
    
    clk_set_parent(dram_apb_src, sys1_pll_40m);(busfreq-imx8mq.c)
    
    commit 926bf91248dd
    ("clk: imx8m: fix clock tree update of TF-A managed clocks") adds this
    method and enables 8mm, 8mn and 8mq. i.MX8MP also needs it.
    
    This is safe to do, because updating the Linux clock tree to reflect
    reality will always be glitch-free.
    
    Another reason to this patch is that powersave image BT music
    requires dram to be 400MTS, so clk_set_parent(dram_alt_src,
    sys1_pll_800m); is required. Without this patch, it will not succeed.
    
    Fixes: 936c383673b9 ("clk: imx: fix composite peripheral flags")
    Signed-off-by: Zhipeng Wang <[email protected]>
    Reviewed-by: Ahmad Fatoum <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: imx8qxp: Parent should be initialized earlier than the clock [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Jun 7 21:33:46 2024 +0800

    clk: imx: imx8qxp: Parent should be initialized earlier than the clock
    
    [ Upstream commit 766c386c16c9899461b83573a06380d364c6e261 ]
    
    The initialization order of SCU clocks affects the sequence of SCU clock
    resume. If there are no other effects, the earlier the initialization,
    the earlier the resume. During SCU clock resume, the clock rate is
    restored. As SCFW guidelines, configure the parent clock rate before
    configuring the child rate.
    
    Fixes: babfaa9556d7 ("clk: imx: scu: add more scu clocks")
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Jun 7 21:33:45 2024 +0800

    clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk
    
    [ Upstream commit e61352d5ecdc0da2e7253121c15d9a3e040f78a1 ]
    
    The initialization order of SCU clocks affects the sequence of SCU clock
    resume. If there are no other effects, the earlier the initialization,
    the earlier the resume. During SCU clock resume, the clock rate is
    restored. As SCFW guidelines, configure the parent clock rate before
    configuring the child rate.
    
    Fixes: 91e916771de0 ("clk: imx: scu: remove legacy scu clock binding support")
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Abel Vesa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Abel Vesa <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Aug 4 08:40:06 2024 +0300

    clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL
    
    [ Upstream commit 362be5cbaec2a663eb86b7105313368b4a71fc1e ]
    
    According to msm-5.10 the lucid 5lpe PLLs have require slightly
    different configuration that trion / lucid PLLs, it doesn't set
    PLL_UPDATE_BYPASS bit. Add corresponding function and use it for the
    display clock controller on Qualcomm SM8350 platform.
    
    Fixes: 205737fe3345 ("clk: qcom: add support for SM8350 DISPCC")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8550: fix several supposed typos [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jul 17 13:04:28 2024 +0300

    clk: qcom: dispcc-sm8550: fix several supposed typos
    
    [ Upstream commit 7b6a4b907297b28727933493b9e0c95494504634 ]
    
    Fix seveal odd-looking places in SM8550's dispcc driver:
    
    - duplicate entries in disp_cc_parent_map_4 and disp_cc_parent_map_5
    - using &disp_cc_mdss_dptx0_link_div_clk_src as a source for
      disp_cc_mdss_dptx1_usb_router_link_intf_clk
    
    The SM8650 driver has been used as a reference.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jul 17 13:04:29 2024 +0300

    clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src
    
    [ Upstream commit cb4c00698f2f27d99a69adcce659370ca286cf2a ]
    
    clk_dp_ops should only be used for DisplayPort pixel clocks. Use
    clk_rcg2_ops for disp_cc_mdss_dptx1_aux_clk_src.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jul 17 13:04:32 2024 +0300

    clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs
    
    [ Upstream commit c8bee3ff6c9220092b646ff929f9c832c1adab6d ]
    
    Follow the recommendations and park disp_cc_mdss_esc[01]_clk_src to the
    XO instead of disabling the clocks by using the clk_rcg2_shared_ops.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: dispcc-sm8650: Update the GDSC flags [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Wed Jul 17 13:04:31 2024 +0300

    clk: qcom: dispcc-sm8650: Update the GDSC flags
    
    [ Upstream commit 7de10ddbdb9d03651cff5fbdc8cf01837c698526 ]
    
    Add missing POLL_CFG_GDSCR to the MDSS GDSC flags.
    
    Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Neil Armstrong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src [+ + +]
Author: Varadarajan Narayanan <[email protected]>
Date:   Tue Jul 30 11:18:15 2024 +0530

    clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src
    
    [ Upstream commit 0e1ac23dfa3f635e486fdeb08206b981cb0a2a6b ]
    
    gcc_qdss_tsctr_clk_src (enabled in the boot loaders and dependent
    on gpll4_main) was not registered as one of the ipq5332 clocks.
    Hence clk_disable_unused() disabled 'gpll4_main' assuming there
    were no consumers for 'gpll4_main' resulting in system freeze or
    reboots.
    
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC")
    Signed-off-by: Varadarajan Narayanan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p [+ + +]
Author: Alexander Shiyan <[email protected]>
Date:   Thu Aug 29 08:28:20 2024 +0300

    clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p
    
    [ Upstream commit 0d02e8d284a45bfa8997ebe8764437b8eb6b108b ]
    
    The 32kHz input clock is named "xin32k" in the driver,
    so the name "32k" appears to be a typo in this case. Lets fix this.
    
    Signed-off-by: Alexander Shiyan <[email protected]>
    Reviewed-by: Dragan Simic <[email protected]>
    Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228 [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Sat Jun 15 17:03:53 2024 +0000

    clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228
    
    [ Upstream commit 1d34b9757523c1ad547bd6d040381f62d74a3189 ]
    
    Similar to DCLK_LCDC on RK3328, the DCLK_VOP on RK3228 is typically
    parented by the hdmiphy clk and it is expected that the DCLK_VOP and
    hdmiphy clk rate are kept in sync.
    
    Use CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT flags, same as used
    on RK3328, to make full use of all possible supported display modes.
    
    Fixes: 0a9d4ac08ebc ("clk: rockchip: set the clock ids for RK3228 VOP")
    Fixes: 307a2e9ac524 ("clk: rockchip: add clock controller for rk3228")
    Signed-off-by: Jonas Karlman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage [+ + +]
Author: Yuntao Liu <[email protected]>
Date:   Thu Aug 15 09:38:53 2024 +0000

    clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage
    
    [ Upstream commit 55c312c1b2be6d43e39c280ad6ab4b711e545b89 ]
    
    We need to call pm_runtime_put_noidle() when pm_runtime_get_sync()
    fails, so use pm_runtime_resume_and_get() instead. this function
    will handle this.
    
    Fixes: dae5448a327ed ("clk: starfive: Add StarFive JH7110 Video-Output clock driver")
    Signed-off-by: Yuntao Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Xingyu Wu <[email protected]>
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

clk: ti: dra7-atl: Fix leak of of_nodes [+ + +]
Author: David Lechner <[email protected]>
Date:   Mon Aug 26 10:35:29 2024 -0500

    clk: ti: dra7-atl: Fix leak of of_nodes
    
    [ Upstream commit 9d6e9f10e2e031fb7bfb3030a7d1afc561a28fea ]
    
    This fix leaking the of_node references in of_dra7_atl_clk_probe().
    
    The docs for of_parse_phandle_with_args() say that the caller must call
    of_node_put() on the returned node. This adds the missing of_node_put()
    to fix the leak.
    
    Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)")
    Signed-off-by: David Lechner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Stephen Boyd <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
clocksource/drivers/qcom: Add missing iounmap() on errors in msm_dt_timer_init() [+ + +]
Author: Ankit Agrawal <[email protected]>
Date:   Sat Jul 13 15:27:13 2024 +0530

    clocksource/drivers/qcom: Add missing iounmap() on errors in msm_dt_timer_init()
    
    [ Upstream commit ca140a0dc0a18acd4653b56db211fec9b2339986 ]
    
    Add the missing iounmap() when clock frequency fails to get read by the
    of_property_read_u32() call, or if the call to msm_timer_init() fails.
    
    Fixes: 6e3321631ac2 ("ARM: msm: Add DT support to msm_timer")
    Signed-off-by: Ankit Agrawal <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/20240713095713.GA430091@bnew-VirtualBox
    Signed-off-by: Daniel Lezcano <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: tmc: sg: Do not leak sg_table [+ + +]
Author: Suzuki K Poulose <[email protected]>
Date:   Tue Jul 2 14:28:46 2024 +0100

    coresight: tmc: sg: Do not leak sg_table
    
    [ Upstream commit c58dc5a1f886f2fcc1133746d0cbaa1fe7fd44ff ]
    
    Running perf with cs_etm on Juno triggers the following kmemleak warning !
    
    :~# cat /sys/kernel/debug/kmemleak
     unreferenced object 0xffffff8806b6d720 (size 96):
     comm "perf", pid 562, jiffies 4297810960
     hex dump (first 32 bytes):
     38 d8 13 07 88 ff ff ff 00 d0 9e 85 c0 ff ff ff  8...............
     00 10 00 88 c0 ff ff ff 00 f0 ff f7 ff 00 00 00  ................
     backtrace (crc 1dbf6e00):
     [<ffffffc08107381c>] kmemleak_alloc+0xbc/0xd8
     [<ffffffc0802f9798>] kmalloc_trace_noprof+0x220/0x2e8
     [<ffffffc07bb71948>] tmc_alloc_sg_table+0x48/0x208 [coresight_tmc]
     [<ffffffc07bb71cbc>] tmc_etr_alloc_sg_buf+0xac/0x240 [coresight_tmc]
     [<ffffffc07bb72538>] tmc_alloc_etr_buf.constprop.0+0x1f0/0x260 [coresight_tmc]
     [<ffffffc07bb7280c>] alloc_etr_buf.constprop.0.isra.0+0x74/0xa8 [coresight_tmc]
     [<ffffffc07bb72950>] tmc_alloc_etr_buffer+0x110/0x260 [coresight_tmc]
     [<ffffffc07bb38afc>] etm_setup_aux+0x204/0x3b0 [coresight]
     [<ffffffc08025837c>] rb_alloc_aux+0x20c/0x318
     [<ffffffc08024dd84>] perf_mmap+0x2e4/0x7a0
     [<ffffffc0802cceb0>] mmap_region+0x3b0/0xa08
     [<ffffffc0802cd8a8>] do_mmap+0x3a0/0x500
     [<ffffffc080295328>] vm_mmap_pgoff+0x100/0x1d0
     [<ffffffc0802cadf8>] ksys_mmap_pgoff+0xb8/0x110
     [<ffffffc080020688>] __arm64_sys_mmap+0x38/0x58
     [<ffffffc080028fc0>] invoke_syscall.constprop.0+0x58/0x100
    
    This due to the fact that we do not free the "sg_table" itself while
    freeing up  the SG table and data pages. Fix this by freeing the sg_table
    in tmc_free_sg_table().
    
    Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework")
    Cc: Mike Leach <[email protected]>
    Cc: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Reviewed-by: Anshuman Khandual <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately [+ + +]
Author: Nishanth Menon <[email protected]>
Date:   Wed Aug 28 08:19:15 2024 -0500

    cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately
    
    [ Upstream commit abc00ffda43bd4ba85896713464c7510c39f8165 ]
    
    Commit b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx
    and omap36xx") introduced special handling for OMAP3 class devices
    where syscon node may not be present. However, this also creates a bug
    where the syscon node is present, however the offset used to read
    is beyond the syscon defined range.
    
    Fix this by providing a quirk option that is populated when such
    special handling is required. This allows proper failure for all other
    platforms when the syscon node and efuse offsets are mismatched.
    
    Fixes: b4bc9f9e27ed ("cpufreq: ti-cpufreq: add support for omap34xx and omap36xx")
    Signed-off-by: Nishanth Menon <[email protected]>
    Tested-by: Dhruva Gole <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpuidle: riscv-sbi: Use scoped device node handling to fix missing of_node_put [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 20 11:40:22 2024 +0200

    cpuidle: riscv-sbi: Use scoped device node handling to fix missing of_node_put
    
    commit a309320ddbac6b1583224fcb6bacd424bcf8637f upstream.
    
    Two return statements in sbi_cpuidle_dt_init_states() did not drop the
    OF node reference count.  Solve the issue and simplify entire error
    handling with scoped/cleanup.h.
    
    Fixes: 6abf32f1d9c5 ("cpuidle: Add RISC-V SBI CPU idle driver")
    Cc: All applicable <[email protected]>
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Anup Patel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
crypto: caam - Pad SG length when allocating hash edesc [+ + +]
Author: Herbert Xu <[email protected]>
Date:   Thu Sep 12 17:57:13 2024 +0800

    crypto: caam - Pad SG length when allocating hash edesc
    
    [ Upstream commit 5124bc96162667766f6120b19f57a640c2eccb2a ]
    
    Because hardware will read in multiples of 4 SG entries, ensure
    the allocated length is always padded.  This was already done
    by some callers of ahash_edesc_alloc, but ahash_digest was conspicuously
    missing.
    
    In any case, doing it in the allocation function ensures that the
    memory is always there.
    
    Reported-by: Guangwu Zhang <[email protected]>
    Fixes: a5e5c13398f3 ("crypto: caam - fix S/G table passing page boundary")
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure [+ + +]
Author: Pavan Kumar Paluri <[email protected]>
Date:   Thu Aug 15 07:25:00 2024 -0500

    crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure
    
    commit ce3d2d6b150ba8528f3218ebf0cee2c2c572662d upstream.
    
    In case of sev PLATFORM_STATUS failure, sev_get_api_version() fails
    resulting in sev_data field of psp_master nulled out. This later becomes
    a problem when unloading the ccp module because the device has not been
    unregistered (via misc_deregister()) before clearing the sev_data field
    of psp_master. As a result, on reloading the ccp module, a duplicate
    device issue is encountered as can be seen from the dmesg log below.
    
    on reloading ccp module via modprobe ccp
    
    Call Trace:
      <TASK>
      dump_stack_lvl+0xd7/0xf0
      dump_stack+0x10/0x20
      sysfs_warn_dup+0x5c/0x70
      sysfs_create_dir_ns+0xbc/0xd
      kobject_add_internal+0xb1/0x2f0
      kobject_add+0x7a/0xe0
      ? srso_alias_return_thunk+0x5/0xfbef5
      ? get_device_parent+0xd4/0x1e0
      ? __pfx_klist_children_get+0x10/0x10
      device_add+0x121/0x870
      ? srso_alias_return_thunk+0x5/0xfbef5
      device_create_groups_vargs+0xdc/0x100
      device_create_with_groups+0x3f/0x60
      misc_register+0x13b/0x1c0
      sev_dev_init+0x1d4/0x290 [ccp]
      psp_dev_init+0x136/0x300 [ccp]
      sp_init+0x6f/0x80 [ccp]
      sp_pci_probe+0x2a6/0x310 [ccp]
      ? srso_alias_return_thunk+0x5/0xfbef5
      local_pci_probe+0x4b/0xb0
      work_for_cpu_fn+0x1a/0x30
      process_one_work+0x203/0x600
      worker_thread+0x19e/0x350
      ? __pfx_worker_thread+0x10/0x10
      kthread+0xeb/0x120
      ? __pfx_kthread+0x10/0x10
      ret_from_fork+0x3c/0x60
      ? __pfx_kthread+0x10/0x10
      ret_from_fork_asm+0x1a/0x30
      </TASK>
      kobject: kobject_add_internal failed for sev with -EEXIST, don't try to register things with the same name in the same directory.
      ccp 0000:22:00.1: sev initialization failed
      ccp 0000:22:00.1: psp initialization failed
      ccp 0000:a2:00.1: no command queues available
      ccp 0000:a2:00.1: psp enabled
    
    Address this issue by unregistering the /dev/sev before clearing out
    sev_data in case of PLATFORM_STATUS failure.
    
    Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
    Cc: [email protected]
    Signed-off-by: Pavan Kumar Paluri <[email protected]>
    Acked-by: Tom Lendacky <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

crypto: hisilicon/hpre - mask cluster timeout error [+ + +]
Author: Weili Qian <[email protected]>
Date:   Sat Aug 31 19:48:30 2024 +0800

    crypto: hisilicon/hpre - mask cluster timeout error
    
    [ Upstream commit 145013f723947c83b1a5f76a0cf6e7237d59e973 ]
    
    The timeout threshold of the hpre cluster is 16ms. When the CPU
    and device share virtual address, page fault processing time may
    exceed the threshold.
    
    In the current test, there is a high probability that the
    cluster times out. However, the cluster is waiting for the
    completion of memory access, which is not an error, the device
    does not need to be reset. If an error occurs in the cluster,
    qm also reports the error. Therefore, the cluster timeout
    error of hpre can be masked.
    
    Fixes: d90fab0deb8e ("crypto: hisilicon/qm - get error type from hardware registers")
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - inject error before stopping queue [+ + +]
Author: Weili Qian <[email protected]>
Date:   Sat Aug 31 19:48:31 2024 +0800

    crypto: hisilicon/qm - inject error before stopping queue
    
    [ Upstream commit b04f06fc0243600665b3b50253869533b7938468 ]
    
    The master ooo cannot be completely closed when the
    accelerator core reports memory error. Therefore, the driver
    needs to inject the qm error to close the master ooo. Currently,
    the qm error is injected after stopping queue, memory may be
    released immediately after stopping queue, causing the device to
    access the released memory. Therefore, error is injected to close master
    ooo before stopping queue to ensure that the device does not access
    the released memory.
    
    Fixes: 6c6dd5802c2d ("crypto: hisilicon/qm - add controller reset interface")
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: hisilicon/qm - reset device before enabling it [+ + +]
Author: Weili Qian <[email protected]>
Date:   Sat Aug 31 19:48:29 2024 +0800

    crypto: hisilicon/qm - reset device before enabling it
    
    [ Upstream commit 5d2d1ee0874c26b8010ddf7f57e2f246e848af38 ]
    
    Before the device is enabled again, the device may still
    store the previously processed data. If an error occurs in
    the previous task, the device may fail to be enabled again.
    Therefore, before enabling device, reset the device to restore
    the initial state.
    
    Signed-off-by: Weili Qian <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Stable-dep-of: b04f06fc0243 ("crypto: hisilicon/qm - inject error before stopping queue")
    Signed-off-by: Sasha Levin <[email protected]>

crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10 [+ + +]
Author: Danny Tsen <[email protected]>
Date:   Thu Sep 19 07:36:37 2024 -0400

    crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10
    
    [ Upstream commit 44ac4625ea002deecd0c227336c95b724206c698 ]
    
    Data mismatch found when testing ipsec tunnel with AES/GCM crypto.
    Disabling CRYPTO_AES_GCM_P10 in Kconfig for this feature.
    
    Fixes: fd0e9b3e2ee6 ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched implementation")
    Fixes: cdcecfd9991f ("crypto: p10-aes-gcm - Glue code for AES/GCM stitched implementation")
    Fixes: 45a4672b9a6e2 ("crypto: p10-aes-gcm - Update Kconfig and Makefile")
    Signed-off-by: Danny Tsen <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

crypto: xor - fix template benchmarking [+ + +]
Author: Helge Deller <[email protected]>
Date:   Mon Jul 8 14:24:52 2024 +0200

    crypto: xor - fix template benchmarking
    
    [ Upstream commit ab9a244c396aae4aaa34b2399b82fc15ec2df8c1 ]
    
    Commit c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
    switched from using jiffies to ktime-based performance benchmarking.
    
    This works nicely on machines which have a fine-grained ktime()
    clocksource as e.g. x86 machines with TSC.
    But other machines, e.g. my 4-way HP PARISC server, don't have such
    fine-grained clocksources, which is why it seems that 800 xor loops
    take zero seconds, which then shows up in the logs as:
    
     xor: measuring software checksum speed
        8regs           : -1018167296 MB/sec
        8regs_prefetch  : -1018167296 MB/sec
        32regs          : -1018167296 MB/sec
        32regs_prefetch : -1018167296 MB/sec
    
    Fix this with some small modifications to the existing code to improve
    the algorithm to always produce correct results without introducing
    major delays for architectures with a fine-grained ktime()
    clocksource:
    a) Delay start of the timing until ktime() just advanced. On machines
    with a fast ktime() this should be just one additional ktime() call.
    b) Count the number of loops. Run at minimum 800 loops and finish
    earliest when the ktime() counter has progressed.
    
    With that the throughput can now be calculated more accurately under all
    conditions.
    
    Fixes: c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking")
    Signed-off-by: Helge Deller <[email protected]>
    Tested-by: John David Anglin <[email protected]>
    
    v2:
    - clean up coding style (noticed & suggested by Herbert Xu)
    - rephrased & fixed typo in commit message
    
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cxl/pci: Fix to record only non-zero ranges [+ + +]
Author: Yanfei Xu <[email protected]>
Date:   Wed Aug 28 16:42:28 2024 +0800

    cxl/pci: Fix to record only non-zero ranges
    
    [ Upstream commit 55e268694e8b07026c88191f9b6949b6887d9ce3 ]
    
    The function cxl_dvsec_rr_decode() retrieves and records DVSEC ranges
    into info->dvsec_range[], regardless of whether it is non-zero range,
    and the variable info->ranges indicates the number of non-zero ranges.
    However, in cxl_hdm_decode_init(), the validation for
    info->dvsec_range[] occurs in a for loop that iterates based on
    info->ranges. It may result in zero range to be validated but non-zero
    range not be validated, in turn, the number of allowed ranges is to be
    0. Address it by only record non-zero ranges.
    
    This fix is not urgent as it requires a configuration that zeroes out
    the first dvsec range while populating the second. This has not been
    observed, but it is theoretically possible. If this gets picked up for
    -stable, no harm done, but there is no urgency to backport.
    
    Fixes: 560f78559006 ("cxl/pci: Retrieve CXL DVSEC memory info")
    Reviewed-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Yanfei Xu <[email protected]>
    Reviewed-by: Alison Schofield <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Dave Jiang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
debugobjects: Fix conditions in fill_pool() [+ + +]
Author: Zhen Lei <[email protected]>
Date:   Wed Sep 4 21:39:40 2024 +0800

    debugobjects: Fix conditions in fill_pool()
    
    commit 684d28feb8546d1e9597aa363c3bfcf52fe250b7 upstream.
    
    fill_pool() uses 'obj_pool_min_free' to decide whether objects should be
    handed back to the kmem cache. But 'obj_pool_min_free' records the lowest
    historical value of the number of objects in the object pool and not the
    minimum number of objects which should be kept in the pool.
    
    Use 'debug_objects_pool_min_level' instead, which holds the minimum number
    which was scaled to the number of CPUs at boot time.
    
    [ tglx: Massage change log ]
    
    Fixes: d26bf5056fc0 ("debugobjects: Reduce number of pool_lock acquisitions in fill_pool()")
    Fixes: 36c4ead6f6df ("debugobjects: Add global free list and the counter")
    Signed-off-by: Zhen Lei <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dm-verity: restart or panic on an I/O error [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Tue Sep 24 15:18:29 2024 +0200

    dm-verity: restart or panic on an I/O error
    
    commit e6a3531dd542cb127c8de32ab1e54a48ae19962b upstream.
    
    Maxim Suhanov reported that dm-verity doesn't crash if an I/O error
    happens. In theory, this could be used to subvert security, because an
    attacker can create sectors that return error with the Write Uncorrectable
    command. Some programs may misbehave if they have to deal with EIO.
    
    This commit fixes dm-verity, so that if "panic_on_corruption" or
    "restart_on_corruption" was specified and an I/O error happens, the
    machine will panic or restart.
    
    This commit also changes kernel_restart to emergency_restart -
    kernel_restart calls reboot notifiers and these reboot notifiers may wait
    for the bio that failed. emergency_restart doesn't call the notifiers.
    
    Reported-by: Maxim Suhanov <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Documentation: KVM: fix warning in "make htmldocs" [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Fri Sep 27 11:45:45 2024 -0400

    Documentation: KVM: fix warning in "make htmldocs"
    
    commit efbc6bd090f48ccf64f7a8dd5daea775821d57ec upstream.
    
    The warning
    
     Documentation/virt/kvm/locking.rst:31: ERROR: Unexpected indentation.
    
    is caused by incorrectly treating a line as the continuation of a paragraph,
    rather than as the first line in a bullet list.
    
    Fixed: 44d174596260 ("KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock")
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drbd: Add NULL check for net_conf to prevent dereference in state validation [+ + +]
Author: Mikhail Lobanov <[email protected]>
Date:   Mon Sep 9 09:37:36 2024 -0400

    drbd: Add NULL check for net_conf to prevent dereference in state validation
    
    commit a5e61b50c9f44c5edb6e134ede6fee8806ffafa9 upstream.
    
    If the net_conf pointer is NULL and the code attempts to access its
    fields without a check, it will lead to a null pointer dereference.
    Add a NULL check before dereferencing the pointer.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 44ed167da748 ("drbd: rcu_read_lock() and rcu_dereference() for tconn->net_conf")
    Cc: [email protected]
    Signed-off-by: Mikhail Lobanov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drbd: Fix atomicity violation in drbd_uuid_set_bm() [+ + +]
Author: Qiu-ji Chen <[email protected]>
Date:   Fri Sep 13 16:35:04 2024 +0800

    drbd: Fix atomicity violation in drbd_uuid_set_bm()
    
    commit 2f02b5af3a4482b216e6a466edecf6ba8450fa45 upstream.
    
    The violation of atomicity occurs when the drbd_uuid_set_bm function is
    executed simultaneously with modifying the value of
    device->ldev->md.uuid[UI_BITMAP]. Consider a scenario where, while
    device->ldev->md.uuid[UI_BITMAP] passes the validity check when its
    value is not zero, the value of device->ldev->md.uuid[UI_BITMAP] is
    written to zero. In this case, the check in drbd_uuid_set_bm might refer
    to the old value of device->ldev->md.uuid[UI_BITMAP] (before locking),
    which allows an invalid value to pass the validity check, resulting in
    inconsistency.
    
    To address this issue, it is recommended to include the data validity
    check within the locked section of the function. This modification
    ensures that the value of device->ldev->md.uuid[UI_BITMAP] does not
    change during the validation process, thereby maintaining its integrity.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team. This tool analyzes the locking APIs to extract
    function pairs that can be concurrently executed, and then analyzes the
    instructions in the paired functions to identify possible concurrency
    bugs including data races and atomicity violations.
    
    Fixes: 9f2247bb9b75 ("drbd: Protect accesses to the uuid set with a spinlock")
    Cc: [email protected]
    Signed-off-by: Qiu-ji Chen <[email protected]>
    Reviewed-by: Philipp Reisner <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
driver core: Fix a potential null-ptr-deref in module_add_driver() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Aug 12 16:06:58 2024 +0800

    driver core: Fix a potential null-ptr-deref in module_add_driver()
    
    [ Upstream commit 18ec12c97b39ff6aa15beb8d2b25d15cd44b87d8 ]
    
    Inject fault while probing of-fpga-region, if kasprintf() fails in
    module_add_driver(), the second sysfs_remove_link() in exit path will cause
    null-ptr-deref as below because kernfs_name_hash() will call strlen() with
    NULL driver_name.
    
    Fix it by releasing resources based on the exit path sequence.
    
             KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
             Mem abort info:
               ESR = 0x0000000096000005
               EC = 0x25: DABT (current EL), IL = 32 bits
               SET = 0, FnV = 0
               EA = 0, S1PTW = 0
               FSC = 0x05: level 1 translation fault
             Data abort info:
               ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
               CM = 0, WnR = 0, TnD = 0, TagAccess = 0
               GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
             [dfffffc000000000] address between user and kernel address ranges
             Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
             Dumping ftrace buffer:
                (ftrace buffer empty)
             Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region]
             CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295
             Hardware name: linux,dummy-virt (DT)
             pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
             pc : strlen+0x24/0xb0
             lr : kernfs_name_hash+0x1c/0xc4
             sp : ffffffc081f97380
             x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0
             x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000
             x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
             x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840
             x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42
             x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d
             x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000
             x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001
             x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000
             x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000
             Call trace:
              strlen+0x24/0xb0
              kernfs_name_hash+0x1c/0xc4
              kernfs_find_ns+0x118/0x2e8
              kernfs_remove_by_name_ns+0x80/0x100
              sysfs_remove_link+0x74/0xa8
              module_add_driver+0x278/0x394
              bus_add_driver+0x1f0/0x43c
              driver_register+0xf4/0x3c0
              __platform_driver_register+0x60/0x88
              of_fpga_region_init+0x20/0x1000 [of_fpga_region]
              do_one_initcall+0x110/0x788
              do_init_module+0x1dc/0x5c8
              load_module+0x3c38/0x4cac
              init_module_from_file+0xd4/0x128
              idempotent_init_module+0x2cc/0x528
              __arm64_sys_finit_module+0xac/0x100
              invoke_syscall+0x6c/0x258
              el0_svc_common.constprop.0+0x160/0x22c
              do_el0_svc+0x44/0x5c
              el0_svc+0x48/0xb8
              el0t_64_sync_handler+0x13c/0x158
              el0t_64_sync+0x190/0x194
             Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861)
             ---[ end trace 0000000000000000 ]---
             Kernel panic - not syncing: Oops: Fatal exception
    
    Fixes: 85d2b0aa1703 ("module: don't ignore sysfs_create_link() failures")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

driver core: Fix error handling in driver API device_rename() [+ + +]
Author: Zijun Hu <[email protected]>
Date:   Mon Jul 22 22:48:10 2024 +0800

    driver core: Fix error handling in driver API device_rename()
    
    [ Upstream commit 6d8249ac29bc23260dfa9747eb398ce76012d73c ]
    
    For class-device, device_rename() failure maybe cause unexpected link name
    within its class folder as explained below:
    
    /sys/class/.../old_name -> /sys/devices/.../old_name
    device_rename(..., new_name) and failed
    /sys/class/.../new_name -> /sys/devices/.../old_name
    
    Fixed by undoing renaming link if renaming kobject failed.
    
    Fixes: f349cf34731c ("driver core: Implement ns directory support for device classes.")
    Signed-off-by: Zijun Hu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers/perf: Fix ali_drw_pmu driver interrupt status clearing [+ + +]
Author: Jing Zhang <[email protected]>
Date:   Thu Aug 22 11:33:31 2024 +0800

    drivers/perf: Fix ali_drw_pmu driver interrupt status clearing
    
    [ Upstream commit a3dd920977dccc453c550260c4b7605b280b79c3 ]
    
    The alibaba_uncore_pmu driver forgot to clear all interrupt status
    in the interrupt processing function. After the PMU counter overflow
    interrupt occurred, an interrupt storm occurred, causing the system
    to hang.
    
    Therefore, clear the correct interrupt status in the interrupt handling
    function to fix it.
    
    Fixes: cf7b61073e45 ("drivers/perf: add DDR Sub-System Driveway PMU driver for Yitian 710 SoC")
    Signed-off-by: Jing Zhang <[email protected]>
    Reviewed-by: Shuai Xue <[email protected]>
    Acked-by: Mark Rutland <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Thu Aug 29 17:03:31 2024 +0800

    drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting
    
    [ Upstream commit 17bf68aeb3642221e3e770399b5a52f370747ac1 ]
    
    We make the initial value of event ctrl register as HISI_PCIE_INIT_SET
    and modify according to the user options. This will make TLP headers
    bandwidth only counting never take effect since HISI_PCIE_INIT_SET
    configures to count the TLP payloads bandwidth. Fix this by making
    the initial value of event ctrl register as 0.
    
    Fixes: 17d573984d4d ("drivers/perf: hisi: Add TLP filter support")
    Signed-off-by: Yicong Yang <[email protected]>
    Acked-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers/perf: hisi_pcie: Record hardware counts correctly [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Thu Aug 29 17:03:30 2024 +0800

    drivers/perf: hisi_pcie: Record hardware counts correctly
    
    [ Upstream commit daecd3373a16a039ad241086e30a1ec46fc9d61f ]
    
    Currently we set the period and record it as the initial value of the
    counter without checking it's set to the hardware successfully or not.
    However the counter maybe unwritable if the target event is unsupported
    by the device. In such case we will pass user a wrong count:
    
    [start counts when setting the period]
    hwc->prev_count = 0x8000000000000000
    device.counter_value = 0 // the counter is not set as the period
    [when user reads the counter]
    event->count = device.counter_value - hwc->prev_count
                 = 0x8000000000000000 // wrong. should be 0.
    
    Fix this by record the hardware counter counts correctly when setting
    the period.
    
    Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
    Signed-off-by: Yicong Yang <[email protected]>
    Acked-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error [+ + +]
Author: Junlin Li <[email protected]>
Date:   Wed Jul 3 01:50:23 2024 +0800

    drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
    
    [ Upstream commit 46d7ebfe6a75a454a5fa28604f0ef1491f9d8d14 ]
    
    Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
    out-of-bounds access.
    
    dev->filters is a 32-bit value, so set_bit and clear_bit functions should
    only operate on indices from 0 to 31. If index is 32, it will attempt to
    access a non-existent 33rd bit, leading to out-of-bounds access.
    Change the boundary check from index > 32 to index >= 32 to resolve this
    issue.
    
    Fixes: df70ddad81b4 ("[media] rtl2830: implement PID filter")
    Signed-off-by: Junlin Li <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error [+ + +]
Author: Junlin Li <[email protected]>
Date:   Tue Jul 2 21:24:13 2024 +0800

    drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
    
    [ Upstream commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 ]
    
    Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
    out-of-bounds access.
    
    dev->filters is a 32-bit value, so set_bit and clear_bit functions should
    only operate on indices from 0 to 31. If index is 32, it will attempt to
    access a non-existent 33rd bit, leading to out-of-bounds access.
    Change the boundary check from index > 32 to index >= 32 to resolve this
    issue.
    
    Signed-off-by: Junlin Li <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter")
    [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind() [+ + +]
Author: Yuesong Li <[email protected]>
Date:   Thu Aug 22 17:09:27 2024 +0800

    drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()
    
    [ Upstream commit 94ebc3d3235c5c516f67315059ce657e5090e94b ]
    
    cocci reported a double assignment problem. Upon reviewing previous
    commits, it appears this may actually be an incorrect assignment.
    
    Fixes: 8b9550344d39 ("drm/ipp: clean up debug messages")
    Signed-off-by: Yuesong Li <[email protected]>
    Signed-off-by: Inki Dae <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/amdgpu: Properly tune the size of struct [+ + +]
Author: WangYuli <[email protected]>
Date:   Wed Jul 31 12:10:40 2024 +0800

    drm/amd/amdgpu: Properly tune the size of struct
    
    [ Upstream commit 0cee47cde41e22712c034ae961076067d4ac13a0 ]
    
    The struct assertion is failed because sparse cannot parse
    `#pragma pack(push, 1)` and `#pragma pack(pop)` correctly.
    GCC's output is still 1-byte-aligned. No harm to memory layout.
    
    The error can be filtered out by sparse-diff, but sometimes
    multiple lines queezed into one, making the sparse-diff thinks
    its a new error. I'm trying to aviod this by fixing errors.
    
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/all/[email protected]/
    Fixes: 1721bc1b2afa ("drm/amdgpu: Update VF2PF interface")
    Cc: Dan Carpenter <[email protected]>
    Cc: wenlunpeng <[email protected]>
    Reported-by: Su Hui <[email protected]>
    Signed-off-by: WangYuli <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add HDMI DSC native YCbCr422 support [+ + +]
Author: Leo Ma <[email protected]>
Date:   Mon Aug 19 13:25:27 2024 -0400

    drm/amd/display: Add HDMI DSC native YCbCr422 support
    
    commit 07bfa9cdbf3cd2daadfaaba0601f126f45951ffa upstream.
    
    [WHY && HOW]
    For some HDMI OVT timing, YCbCr422 encoding fails at the DSC
    bandwidth check. The root cause is our DSC policy for timing
    doesn't account for HDMI YCbCr422 native support.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Chris Park <[email protected]>
    Signed-off-by: Leo Ma <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func [+ + +]
Author: Srinivasan Shanmugam <[email protected]>
Date:   Mon Jul 22 17:18:17 2024 +0530

    drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func
    
    [ Upstream commit 08ae395ea22fb3d9b318c8bde28c0dfd2f5fa4d2 ]
    
    This commit adds a null check for the set_output_gamma function pointer
    in the  dcn30_set_output_transfer_func function. Previously,
    set_output_gamma was being checked for nullity at line 386, but then it
    was being dereferenced without any nullity check at line 401. This
    could potentially lead to a null pointer dereference error if
    set_output_gamma is indeed null.
    
    To fix this, we now ensure that set_output_gamma is not null before
    dereferencing it. We do this by adding a nullity check for
    set_output_gamma before the call to set_output_gamma at line 401. If
    set_output_gamma is null, we log an error message and do not call the
    function.
    
    This fix prevents a potential null pointer dereference error.
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()
    error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386)
    
    drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c
        373 bool dcn30_set_output_transfer_func(struct dc *dc,
        374                                 struct pipe_ctx *pipe_ctx,
        375                                 const struct dc_stream_state *stream)
        376 {
        377         int mpcc_id = pipe_ctx->plane_res.hubp->inst;
        378         struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc;
        379         const struct pwl_params *params = NULL;
        380         bool ret = false;
        381
        382         /* program OGAM or 3DLUT only for the top pipe*/
        383         if (pipe_ctx->top_pipe == NULL) {
        384                 /*program rmu shaper and 3dlut in MPC*/
        385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);
        386                 if (ret == false && mpc->funcs->set_output_gamma) {
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL
    
        387                         if (stream->out_transfer_func.type == TF_TYPE_HWPWL)
        388                                 params = &stream->out_transfer_func.pwl;
        389                         else if (pipe_ctx->stream->out_transfer_func.type ==
        390                                         TF_TYPE_DISTRIBUTED_POINTS &&
        391                                         cm3_helper_translate_curve_to_hw_format(
        392                                         &stream->out_transfer_func,
        393                                         &mpc->blender_params, false))
        394                                 params = &mpc->blender_params;
        395                          /* there are no ROM LUTs in OUTGAM */
        396                         if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED)
        397                                 BREAK_TO_DEBUGGER();
        398                 }
        399         }
        400
    --> 401         mpc->funcs->set_output_gamma(mpc, mpcc_id, params);
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash
    
        402         return ret;
        403 }
    
    Fixes: d99f13878d6f ("drm/amd/display: Add DCN3 HWSEQ")
    Reported-by: Dan Carpenter <[email protected]>
    Cc: Tom Chung <[email protected]>
    Cc: Rodrigo Siqueira <[email protected]>
    Cc: Roman Li <[email protected]>
    Cc: Hersen Wu <[email protected]>
    Cc: Alex Hung <[email protected]>
    Cc: Aurabindo Pillai <[email protected]>
    Cc: Harry Wentland <[email protected]>
    Cc: Hamza Mahfooz <[email protected]>
    Signed-off-by: Srinivasan Shanmugam <[email protected]>
    Reviewed-by: Tom Chung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination [+ + +]
Author: Fangzhi Zuo <[email protected]>
Date:   Mon Aug 12 12:13:44 2024 -0400

    drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination
    
    commit 4437936c6b696b98f3fe1d8679a2788c41b4df77 upstream.
    
    Synaptics Cascaded Panamera topology needs to unconditionally
    acquire root aux for dsc decoding.
    
    Reviewed-by: Roman Li <[email protected]>
    Signed-off-by: Fangzhi Zuo <[email protected]>
    Signed-off-by: Zaeem Mohamed <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: Mario Limonciello <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Round calculated vtotal [+ + +]
Author: Robin Chen <[email protected]>
Date:   Fri Aug 23 15:00:28 2024 +0800

    drm/amd/display: Round calculated vtotal
    
    commit c03fca619fc687338a3b6511fdbed94096abdf79 upstream.
    
    [WHY]
    The calculated vtotal may has 1 line deviation. To get precisely
    vtotal number, round the vtotal result.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Anthony Koo <[email protected]>
    Signed-off-by: Robin Chen <[email protected]>
    Signed-off-by: Alex Hung <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Skip Recompute DSC Params if no Stream on Link [+ + +]
Author: Fangzhi Zuo <[email protected]>
Date:   Fri Jul 12 16:30:03 2024 -0400

    drm/amd/display: Skip Recompute DSC Params if no Stream on Link
    
    commit 8151a6c13111b465dbabe07c19f572f7cbd16fef upstream.
    
    [why]
    Encounter NULL pointer dereference uner mst + dsc setup.
    
    BUG: kernel NULL pointer dereference, address: 0000000000000008
        PGD 0 P4D 0
        Oops: 0000 [#1] PREEMPT SMP NOPTI
        CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
        Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
        RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
        Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>
        RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
        RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
        RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
        RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
        R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
        R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
        FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
        Call Trace:
    <TASK>
         ? __die+0x23/0x70
         ? page_fault_oops+0x171/0x4e0
         ? plist_add+0xbe/0x100
         ? exc_page_fault+0x7c/0x180
         ? asm_exc_page_fault+0x26/0x30
         ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
         ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
         compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
         ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
         compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
         amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
         drm_atomic_check_only+0x5c5/0xa40
         drm_mode_atomic_ioctl+0x76e/0xbc0
    
    [how]
    dsc recompute should be skipped if no mode change detected on the new
    request. If detected, keep checking whether the stream is already on
    current state or not.
    
    Cc: Mario Limonciello <[email protected]>
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Reviewed-by: Rodrigo Siqueira <[email protected]>
    Signed-off-by: Fangzhi Zuo <[email protected]>
    Signed-off-by: Wayne Lin <[email protected]>
    Tested-by: Daniel Wheeler <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/amd/display: Validate backlight caps are sane [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Fri Sep 13 13:00:39 2024 -0500

    drm/amd/display: Validate backlight caps are sane
    
    commit 327e62f47eb57ae5ff63de82b0815557104e439a upstream.
    
    Currently amdgpu takes backlight caps provided by the ACPI tables
    on systems as is.  If the firmware sets maximums that are too low
    this means that users don't get a good experience.
    
    To avoid having to maintain a quirk list of such systems, do a sanity
    check on the values.  Check that the spread is at least half of the
    values that amdgpu would use if no ACPI table was found and if not
    use the amdgpu defaults.
    
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3020
    Reviewed-by: Harry Wentland <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdgpu: properly handle vbios fake edid sizing [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue Jul 23 13:23:56 2024 -0400

    drm/amdgpu: properly handle vbios fake edid sizing
    
    [ Upstream commit 8155566a26b8d6c1dd914f06a0c652e4e2f2adf1 ]
    
    The comment in the vbios structure says:
    // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128
    
    This fake edid struct has not been used in a long time, so I'm
    not sure if there were actually any boards out there with a non-128 byte
    EDID, but align the code with the comment.
    
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Reported-by: Thomas Weißschuh <[email protected]>
    Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/109964.html
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid() [+ + +]
Author: Liu Ying <[email protected]>
Date:   Tue Aug 13 17:16:37 2024 +0800

    drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()
    
    [ Upstream commit fe828fbd87786238b30f44cafd698d975d956c97 ]
    
    If the bridge is attached with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
    this driver won't initialize a connector and hence display mode won't be
    validated in drm_connector_helper_funcs::mode_valid().  So, move the mode
    validation from drm_connector_helper_funcs::mode_valid() to
    drm_bridge_funcs::mode_valid(), because the mode validation is always done
    for the bridge.
    
    Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
    Signed-off-by: Liu Ying <[email protected]>
    Reviewed-by: Robert Foss <[email protected]>
    Signed-off-by: Robert Foss <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config() [+ + +]
Author: Jason-JH.Lin <[email protected]>
Date:   Tue Aug 27 22:55:19 2024 +0800

    drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()
    
    [ Upstream commit fe30bae552ce27b9fefe0b12db1544e73d07325f ]
    
    In mtk_crtc_ddp_config(), mtk_crtc will use some configuration flags to
    generate instructions to cmdq_handle, such as:
      state->pending_config
      mtk_crtc->pending_planes
      plane_state->pending.config
      mtk_crtc->pending_async_planes
      plane_state->pending.async_config
    
    These configuration flags may be set to false when a GCE IRQ comes calling
    ddp_cmdq_cb(). This may result in missing prepare instructions,
    especially if mtk_crtc_update_config() with the flase need_vblank (no need
    to wait for vblank) cases.
    
    Therefore, the mtk_crtc->config_updating flag is set at the beginning of
    mtk_crtc_update_config() to ensure that these configuration flags won't be
    changed when the mtk_crtc_ddp_config() is preparing instructions.
    But somehow the ddp_cmdq_cb() didn't use the mtk_crtc->config_updating
    flag to prevent those pending config flags from being cleared.
    
    To avoid missing the configuration when generating the config instruction,
    the config_updating flag should be added into ddp_cmdq_cb() and be
    protected with spin_lock.
    
    Fixes: 7f82d9c43879 ("drm/mediatek: Clear pending flag when cmdq packet is done")
    Signed-off-by: Jason-JH.Lin <[email protected]>
    Reviewed-by: CK Hu <[email protected]>
    Reviewed-by: Fei Shao <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/mediatek: Use spin_lock_irqsave() for CRTC event lock [+ + +]
Author: Fei Shao <[email protected]>
Date:   Wed Aug 28 18:14:47 2024 +0800

    drm/mediatek: Use spin_lock_irqsave() for CRTC event lock
    
    [ Upstream commit be03b30b7aa99aca876fbc7c1c1b73b2d0339321 ]
    
    Use the state-aware spin_lock_irqsave() and spin_unlock_irqrestore()
    to avoid unconditionally re-enabling the local interrupts.
    
    Fixes: 411f5c1eacfe ("drm/mediatek: handle events when enabling/disabling crtc")
    Signed-off-by: Fei Shao <[email protected]>
    Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/
    Signed-off-by: Chun-Kuang Hu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/a5xx: disable preemption in submits by default [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:00 2024 +0000

    drm/msm/a5xx: disable preemption in submits by default
    
    [ Upstream commit db9dec2db76146d65e1cfbb6afb2e2bd5dab67f8 ]
    
    Fine grain preemption (switching from/to points within submits)
    requires extra handling in command stream of those submits, especially
    when rendering with tiling (using GMEM). However this handling is
    missing at this point in mesa (and always was). For this reason we get
    random GPU faults and hangs if more than one priority level is used
    because local preemption is enabled prior to executing command stream
    from submit.
    With that said it was ahead of time to enable local preemption by
    default considering the fact that even on downstream kernel it is only
    enabled if requested via UAPI.
    
    Fixes: a7a4c19c36de ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612041/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/a5xx: fix races in preemption evaluation stage [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:02 2024 +0000

    drm/msm/a5xx: fix races in preemption evaluation stage
    
    [ Upstream commit ce050f307ad93bcc5958d0dd35fc276fd394d274 ]
    
    On A5XX GPUs when preemption is used it's invietable to enter a soft
    lock-up state in which GPU is stuck at empty ring-buffer doing nothing.
    This appears as full UI lockup and not detected as GPU hang (because
    it's not). This happens due to not triggering preemption when it was
    needed. Sometimes this state can be recovered by some new submit but
    generally it won't happen because applications are waiting for old
    submits to retire.
    
    One of the reasons why this happens is a race between a5xx_submit and
    a5xx_preempt_trigger called from IRQ during submit retire. Former thread
    updates ring->cur of previously empty and not current ring right after
    latter checks it for emptiness. Then both threads can just exit because
    for first one preempt_state wasn't NONE yet and for second one all rings
    appeared to be empty.
    
    To prevent such situations from happening we need to establish guarantee
    for preempt_trigger to make decision after each submit or retire. To
    implement this we serialize preemption initiation using spinlock. If
    switch is already in progress we need to re-trigger preemption when it
    finishes.
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612045/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/a5xx: properly clear preemption records on resume [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:01 2024 +0000

    drm/msm/a5xx: properly clear preemption records on resume
    
    [ Upstream commit 64fd6d01a52904bdbda0ce810a45a428c995a4ca ]
    
    Two fields of preempt_record which are used by CP aren't reset on
    resume: "data" and "info". This is the reason behind faults which happen
    when we try to switch to the ring that was active last before suspend.
    In addition those faults can't be recovered from because we use suspend
    and resume to do so (keeping values of those fields again).
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Reviewed-by: Konrad Dybcio <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612043/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm/a5xx: workaround early ring-buffer emptiness check [+ + +]
Author: Vladimir Lypak <[email protected]>
Date:   Sun Sep 1 13:54:03 2024 +0000

    drm/msm/a5xx: workaround early ring-buffer emptiness check
    
    [ Upstream commit a30f9f65b5ac82d4390548c32ed9c7f05de7ddf5 ]
    
    There is another cause for soft lock-up of GPU in empty ring-buffer:
    race between GPU executing last commands and CPU checking ring for
    emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS
    event and RPTR shadow (which is used to check ring emptiness) is updated
    a bit later from CP_CONTEXT_SWITCH_YIELD. Thus if GPU is executing its
    last commands slow enough or we check that ring too fast we will miss a
    chance to trigger switch to lower priority ring because current ring isn't
    empty just yet. This can escalate to lock-up situation described in
    previous patch.
    To work-around this issue we keep track of last submit sequence number
    for each ring and compare it with one written to memptrs from GPU during
    execution of CACHE_FLUSH_TS event.
    
    Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets")
    Signed-off-by: Vladimir Lypak <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/612047/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm/dsi: correct programming sequence for SM8350 / SM8450 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sun Aug 4 08:40:07 2024 +0300

    drm/msm/dsi: correct programming sequence for SM8350 / SM8450
    
    [ Upstream commit 1328cb7c34bf6d056df9ff694ee5194537548258 ]
    
    According to the display-drivers, 5nm DSI PLL (v4.2, v4.3) have
    different boundaries for pll_clock_inverters programming. Follow the
    vendor code and use correct values.
    
    Fixes: 2f9ae4e395ed ("drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/606947/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm: fix %s null argument error [+ + +]
Author: Sherry Yang <[email protected]>
Date:   Tue Aug 27 09:53:37 2024 -0700

    drm/msm: fix %s null argument error
    
    [ Upstream commit 25b85075150fe8adddb096db8a4b950353045ee1 ]
    
    The following build error was triggered because of NULL string argument:
    
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c: In function 'mdp5_smp_dump':
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]
    BUILDSTDERR:   352 |                         drm_printf(p, "%s:%d\t%d\t%s\n",
    BUILDSTDERR:       |                                                   ^~
    BUILDSTDERR: drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c:352:51: error: '%s' directive argument is null [-Werror=format-overflow=]
    
    This happens from the commit a61ddb4393ad ("drm: enable (most) W=1
    warnings by default across the subsystem"). Using "(null)" instead
    to fix it.
    
    Fixes: bc5289eed481 ("drm/msm/mdp5: add debugfs to show smp block status")
    Signed-off-by: Sherry Yang <[email protected]>
    Reviewed-by: Abhinav Kumar <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/611071/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/msm: Fix incorrect file name output in adreno_request_fw() [+ + +]
Author: Aleksandr Mishin <[email protected]>
Date:   Fri Jul 5 12:13:12 2024 +0300

    drm/msm: Fix incorrect file name output in adreno_request_fw()
    
    [ Upstream commit e19366911340c2313a1abbb09c54eaf9bdea4f58 ]
    
    In adreno_request_fw() when debugging information is printed to the log
    after firmware load, an incorrect filename is printed. 'newname' is used
    instead of 'fwname', so prefix "qcom/" is being added to filename.
    Looks like "copy-paste" mistake.
    
    Fix this mistake by replacing 'newname' with 'fwname'.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 2c41ef1b6f7d ("drm/msm/adreno: deal with linux-firmware fw paths")
    Signed-off-by: Aleksandr Mishin <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/602382/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Tue Aug 6 10:19:04 2024 -0700

    drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets
    
    [ Upstream commit 3fbaf475a5b8361ebee7da18964db809e37518b7 ]
    
    Several cs track offsets (such as 'track->db_s_read_offset')
    either are initialized with or plainly take big enough values that,
    once shifted 8 bits left, may be hit with integer overflow if the
    resulting values end up going over u32 limit.
    
    Same goes for a few instances of 'surf.layer_size * mslice'
    multiplications that are added to 'offset' variable - they may
    potentially overflow as well and need to be validated properly.
    
    While some debug prints in this code section take possible overflow
    issues into account, simply casting to (unsigned long) may be
    erroneous in its own way, as depending on CPU architecture one is
    liable to get different results.
    
    Fix said problems by:
     - casting 'offset' to fixed u64 data type instead of
     ambiguous unsigned long.
     - casting one of the operands in vulnerable to integer
     overflow cases to u64.
     - adjust format specifiers in debug prints to properly
     represent 'offset' values.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 285484e2d55e ("drm/radeon: add support for evergreen/ni tiling informations v11")
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/radeon: properly handle vbios fake edid sizing [+ + +]
Author: Alex Deucher <[email protected]>
Date:   Tue Jul 23 13:31:58 2024 -0400

    drm/radeon: properly handle vbios fake edid sizing
    
    [ Upstream commit 17c6baff3d5f65c8da164137a58742541a060b2f ]
    
    The comment in the vbios structure says:
    // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128
    
    This fake edid struct has not been used in a long time, so I'm
    not sure if there were actually any boards out there with a non-128 byte
    EDID, but align the code with the comment.
    
    Reviewed-by: Thomas Weißschuh <[email protected]>
    Reported-by: Thomas Weißschuh <[email protected]>
    Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/109964.html
    Fixes: c324acd5032f ("drm/radeon/kms: parse the extended LCD info block")
    Signed-off-by: Alex Deucher <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode [+ + +]
Author: Jonas Karlman <[email protected]>
Date:   Sat Jun 15 17:03:55 2024 +0000

    drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode
    
    [ Upstream commit a5d024541ec466f428e6c514577d511a40779c7b ]
    
    EDID cannot be read on RK3328 until after read_hpd has been called and
    correct io voltage has been configured based on connection status.
    
    When a forced mode is used, e.g. video=1920x1080@60e, the connector
    detect ops, that in turn normally calls the read_hpd, never gets called.
    
    This result in reading EDID to fail in connector get_modes ops.
    
    Call dw_hdmi_rk3328_read_hpd at end of dw_hdmi_rk3328_setup_hpd to
    correct io voltage and allow reading EDID after setup_hpd.
    
    Fixes: 1c53ba8f22a1 ("drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328")
    Signed-off-by: Jonas Karlman <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

drm/rockchip: vop: Allow 4096px width scaling [+ + +]
Author: Alex Bee <[email protected]>
Date:   Sat Jun 15 17:03:54 2024 +0000

    drm/rockchip: vop: Allow 4096px width scaling
    
    [ Upstream commit 0ef968d91a20b5da581839f093f98f7a03a804f7 ]
    
    There is no reason to limit VOP scaling to 3840px width, the limit of
    RK3288, when there are newer VOP versions that support 4096px width.
    
    Change to enforce a maximum of 4096px width plane scaling, the maximum
    supported output width of the VOP versions supported by this driver.
    
    Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
    Signed-off-by: Alex Bee <[email protected]>
    Signed-off-by: Jonas Karlman <[email protected]>
    Signed-off-by: Heiko Stuebner <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/stm: Fix an error handling path in stm_drm_platform_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sat Jan 6 17:54:32 2024 +0100

    drm/stm: Fix an error handling path in stm_drm_platform_probe()
    
    [ Upstream commit ce7c90bfda2656418c69ba0dd8f8a7536b8928d4 ]
    
    If drm_dev_register() fails, a call to drv_load() must be undone, as
    already done in the remove function.
    
    Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Raphael Gallais-Pou <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/20fff7f853f20a48a96db8ff186124470ec4d976.1704560028.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Raphael Gallais-Pou <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

drm/stm: ltdc: check memory returned by devm_kzalloc() [+ + +]
Author: Claudiu Beznea <[email protected]>
Date:   Wed May 31 10:28:54 2023 +0300

    drm/stm: ltdc: check memory returned by devm_kzalloc()
    
    [ Upstream commit fd39730c58890cd7f0a594231e19bb357f28877c ]
    
    devm_kzalloc() can fail and return NULL pointer. Check its return status.
    Identified with Coccinelle (kmerr.cocci script).
    
    Fixes: 484e72d3146b ("drm/stm: ltdc: add support of ycbcr pixel formats")
    Signed-off-by: Claudiu Beznea <[email protected]>
    Acked-by: Raphael Gallais-Pou <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Raphael Gallais-Pou <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get [+ + +]
Author: Stefan Wahren <[email protected]>
Date:   Wed Aug 21 23:40:45 2024 +0200

    drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get
    
    [ Upstream commit f1a54e860b1bc8d824925b5a77f510913880e8d6 ]
    
    The commit 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is
    powered in detect") introduced the necessary power management handling
    to avoid register access while controller is powered down.
    Unfortunately it just print a warning if pm_runtime_resume_and_get()
    fails and proceed anyway.
    
    This could happen during suspend to idle. So we must assume it is unsafe
    to access the HDMI register. So bail out properly.
    
    Fixes: 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is powered in detect")
    Signed-off-by: Stefan Wahren <[email protected]>
    Reviewed-by: Maíra Canal <[email protected]>
    Acked-by: Maxime Ripard <[email protected]>
    Signed-off-by: Maíra Canal <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/vmwgfx: Prevent unmapping active read buffers [+ + +]
Author: Zack Rusin <[email protected]>
Date:   Fri Aug 16 14:32:05 2024 -0400

    drm/vmwgfx: Prevent unmapping active read buffers
    
    commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream.
    
    The kms paths keep a persistent map active to read and compare the cursor
    buffer. These maps can race with each other in simple scenario where:
    a) buffer "a" mapped for update
    b) buffer "a" mapped for compare
    c) do the compare
    d) unmap "a" for compare
    e) update the cursor
    f) unmap "a" for update
    At step "e" the buffer has been unmapped and the read contents is bogus.
    
    Prevent unmapping of active read buffers by simply keeping a count of
    how many paths have currently active maps and unmap only when the count
    reaches 0.
    
    Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
    Cc: Broadcom internal kernel review list <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v5.19+
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Reviewed-by: Martin Krastev <[email protected]>
    Reviewed-by: Maaz Mombasawala <[email protected]>
    [Shivani: Modified to apply on v6.6.y]
    Signed-off-by: Shivani Agarwal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 6 07:30:16 2024 +0200

    dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible
    
    [ Upstream commit c7668ac67bc21aebdd8e2d7f839bfffba31b7713 ]
    
    All compatibles in this binding without prefixes were deprecated, so
    adding a new deprecated one after some time is not allowed, because it
    defies the core logic of deprecating things.
    
    Drop the AK09916 vendorless compatible.
    
    Fixes: 76e28aa97fa0 ("iio: magnetometer: ak8975: add AK09116 support")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Conor Dooley <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: spi: nxp-fspi: add imx8ulp support [+ + +]
Author: Haibo Chen <[email protected]>
Date:   Thu Sep 5 17:43:35 2024 +0800

    dt-bindings: spi: nxp-fspi: add imx8ulp support
    
    [ Upstream commit 12736adc43b7cd5cb83f274f8f37b0f89d107c97 ]
    
    The flexspi on imx8ulp only has 16 number of LUTs, it is different
    with flexspi on other imx SoC which has 32 number of LUTs.
    
    Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node")
    Cc: [email protected]
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Haibo Chen <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dt-bindings: spi: nxp-fspi: support i.MX93 and i.MX95 [+ + +]
Author: Peng Fan <[email protected]>
Date:   Mon Jan 22 17:15:10 2024 +0800

    dt-bindings: spi: nxp-fspi: support i.MX93 and i.MX95
    
    [ Upstream commit 18ab9e9e8889ecba23a5e8b7f8924f09284e33d8 ]
    
    Add i.MX93/95 flexspi compatible strings, which are compatible with
    i.MX8MM
    
    Signed-off-by: Peng Fan <[email protected]>
    Acked-by: Han Xu <[email protected]>
    Acked-by: Conor Dooley <[email protected]>
    Link: https://msgid.link/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: 12736adc43b7 ("dt-bindings: spi: nxp-fspi: add imx8ulp support")
    Signed-off-by: Sasha Levin <[email protected]>

 
EDAC/igen6: Fix conversion of system address to physical memory address [+ + +]
Author: Qiuxu Zhuo <[email protected]>
Date:   Wed Aug 14 14:10:11 2024 +0800

    EDAC/igen6: Fix conversion of system address to physical memory address
    
    commit 0ad875f442e95d69a1145a38aabac2fd29984fe3 upstream.
    
    The conversion of system address to physical memory address (as viewed by
    the memory controller) by igen6_edac is incorrect when the system address
    is above the TOM (Total amount Of populated physical Memory) for Elkhart
    Lake and Ice Lake (Neural Network Processor). Fix this conversion.
    
    Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
    Signed-off-by: Qiuxu Zhuo <[email protected]>
    Signed-off-by: Tony Luck <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/stable/20240814061011.43545-1-qiuxu.zhuo%40intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
EDAC/synopsys: Fix ECC status and IRQ control race condition [+ + +]
Author: Serge Semin <[email protected]>
Date:   Thu Feb 22 21:12:46 2024 +0300

    EDAC/synopsys: Fix ECC status and IRQ control race condition
    
    [ Upstream commit 591c946675d88dcc0ae9ff54be9d5caaee8ce1e3 ]
    
    The race condition around the ECCCLR register access happens in the IRQ
    disable method called in the device remove() procedure and in the ECC IRQ
    handler:
    
      1. Enable IRQ:
         a. ECCCLR = EN_CE | EN_UE
      2. Disable IRQ:
         a. ECCCLR = 0
      3. IRQ handler:
         a. ECCCLR = CLR_CE | CLR_CE_CNT | CLR_CE | CLR_CE_CNT
         b. ECCCLR = 0
         c. ECCCLR = EN_CE | EN_UE
    
    So if the IRQ disabling procedure is called concurrently with the IRQ
    handler method the IRQ might be actually left enabled due to the
    statement 3c.
    
    The root cause of the problem is that ECCCLR register (which since
    v3.10a has been called as ECCCTL) has intermixed ECC status data clear
    flags and the IRQ enable/disable flags. Thus the IRQ disabling (clear EN
    flags) and handling (write 1 to clear ECC status data) procedures must
    be serialised around the ECCCTL register modification to prevent the
    race.
    
    So fix the problem described above by adding the spin-lock around the
    ECCCLR modifications and preventing the IRQ-handler from modifying the
    IRQs enable flags (there is no point in disabling the IRQ and then
    re-enabling it again within a single IRQ handler call, see the
    statements 3a/3b and 3c above).
    
    Fixes: f7824ded4149 ("EDAC/synopsys: Add support for version 3 of the Synopsys EDAC DDR")
    Signed-off-by: Serge Semin <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 35e6dbfe1846 ("EDAC/synopsys: Fix error injection on Zynq UltraScale+")
    Signed-off-by: Sasha Levin <[email protected]>
EDAC/synopsys: Fix error injection on Zynq UltraScale+ [+ + +]
Author: Shubhrajyoti Datta <[email protected]>
Date:   Thu Jul 11 15:36:56 2024 +0530

    EDAC/synopsys: Fix error injection on Zynq UltraScale+
    
    [ Upstream commit 35e6dbfe1846caeafabb49b7575adb36b0aa2269 ]
    
    The Zynq UltraScale+ MPSoC DDR has a disjoint memory from 2GB to 32GB.
    The DDR host interface has a contiguous memory so while injecting
    errors, the driver should remove the hole else the injection fails as
    the address translation is incorrect.
    
    Introduce a get_mem_info() function pointer and set it for Zynq
    UltraScale+ platform to return host address.
    
    Fixes: 1a81361f75d8 ("EDAC, synopsys: Add Error Injection support for ZynqMP DDR controller")
    Signed-off-by: Shubhrajyoti Datta <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Thu Sep 12 17:45:49 2024 +0200

    efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
    
    commit 77d48d39e99170b528e4f2e9fc5d1d64cdedd386 upstream.
    
    The TPM event log table is a Linux specific construct, where the data
    produced by the GetEventLog() boot service is cached in memory, and
    passed on to the OS using an EFI configuration table.
    
    The use of EFI_LOADER_DATA here results in the region being left
    unreserved in the E820 memory map constructed by the EFI stub, and this
    is the memory description that is passed on to the incoming kernel by
    kexec, which is therefore unaware that the region should be reserved.
    
    Even though the utility of the TPM2 event log after a kexec is
    questionable, any corruption might send the parsing code off into the
    weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
    instead, which is always treated as reserved by the E820 conversion
    logic.
    
    Cc: <[email protected]>
    Reported-by: Breno Leitao <[email protected]>
    Tested-by: Usama Arif <[email protected]>
    Reviewed-by: Ilias Apalodimas <[email protected]>
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Sep 11 10:39:15 2024 +0300

    ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()
    
    [ Upstream commit c7f06284a6427475e3df742215535ec3f6cd9662 ]
    
    The psc->div[] array has psc->num_div elements.  These values come from
    when we call clk_hw_register_div().  It's adc_divisors and
    ARRAY_SIZE(adc_divisors)) and so on.  So this condition needs to be >=
    instead of > to prevent an out of bounds read.
    
    Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Alexander Sverdlin <[email protected]>
    Reviewed-by: Nikita Shubin <[email protected]>
    Signed-off-by: Alexander Sverdlin <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
erofs: fix incorrect symlink detection in fast symlink [+ + +]
Author: Gao Xiang <[email protected]>
Date:   Mon Sep 9 11:19:11 2024 +0800

    erofs: fix incorrect symlink detection in fast symlink
    
    [ Upstream commit 9ed50b8231e37b1ae863f5dec8153b98d9f389b4 ]
    
    Fast symlink can be used if the on-disk symlink data is stored
    in the same block as the on-disk inode, so we don’t need to trigger
    another I/O for symlink data.  However, currently fs correction could be
    reported _incorrectly_ if inode xattrs are too large.
    
    In fact, these should be valid images although they cannot be handled as
    fast symlinks.
    
    Many thanks to Colin for reporting this!
    
    Reported-by: Colin Walters <[email protected]>
    Reported-by: https://honggfuzz.dev/
    Link: https://lore.kernel.org/r/[email protected]
    Fixes: 431339ba9042 ("staging: erofs: add inode operations")
    [ Note that it's a runtime misbehavior instead of a security issue. ]
    Signed-off-by: Gao Xiang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: avoid buffer_head leak in ext4_mark_inode_used() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Tue Aug 20 21:22:28 2024 +0800

    ext4: avoid buffer_head leak in ext4_mark_inode_used()
    
    [ Upstream commit 5e5b2a56c57def1b41efd49596621504d7bcc61c ]
    
    Release inode_bitmap_bh from ext4_read_inode_bitmap() in
    ext4_mark_inode_used() to avoid buffer_head leak.
    By the way, remove unneeded goto for invalid ino when inode_bitmap_bh
    is NULL.
    
    Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
    Signed-off-by: Kemeng Shi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: avoid negative min_clusters in find_group_orlov() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Tue Aug 20 21:22:30 2024 +0800

    ext4: avoid negative min_clusters in find_group_orlov()
    
    [ Upstream commit bb0a12c3439b10d88412fd3102df5b9a6e3cd6dc ]
    
    min_clusters is signed integer and will be converted to unsigned
    integer when compared with unsigned number stats.free_clusters.
    If min_clusters is negative, it will be converted to a huge unsigned
    value in which case all groups may not meet the actual desired free
    clusters.
    Set negative min_clusters to 0 to avoid unexpected behavior.
    
    Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
    Signed-off-by: Kemeng Shi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: avoid OOB when system.data xattr changes underneath the filesystem [+ + +]
Author: Thadeu Lima de Souza Cascardo <[email protected]>
Date:   Wed Aug 21 12:23:24 2024 -0300

    ext4: avoid OOB when system.data xattr changes underneath the filesystem
    
    [ Upstream commit c6b72f5d82b1017bad80f9ebf502832fc321d796 ]
    
    When looking up for an entry in an inlined directory, if e_value_offs is
    changed underneath the filesystem by some change in the block device, it
    will lead to an out-of-bounds access that KASAN detects as an UAF.
    
    EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
    loop0: detected capacity change from 2048 to 2047
    ==================================================================
    BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
    Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103
    
    CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:93 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x169/0x550 mm/kasan/report.c:488
     kasan_report+0x143/0x180 mm/kasan/report.c:601
     ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
     ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
     __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
     ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
     ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
     lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
     filename_create+0x297/0x540 fs/namei.c:3980
     do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
     __do_sys_symlinkat fs/namei.c:4610 [inline]
     __se_sys_symlinkat fs/namei.c:4607 [inline]
     __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f3e73ced469
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 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:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
    RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
    RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
    RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
    R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
    R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
     </TASK>
    
    Calling ext4_xattr_ibody_find right after reading the inode with
    ext4_get_inode_loc will lead to a check of the validity of the xattrs,
    avoiding this problem.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=0c2508114d912a54ee79
    Fixes: e8e948e7802a ("ext4: let ext4_find_entry handle inline data")
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: avoid potential buffer_head leak in __ext4_new_inode() [+ + +]
Author: Kemeng Shi <[email protected]>
Date:   Tue Aug 20 21:22:29 2024 +0800

    ext4: avoid potential buffer_head leak in __ext4_new_inode()
    
    [ Upstream commit 227d31b9214d1b9513383cf6c7180628d4b3b61f ]
    
    If a group is marked EXT4_GROUP_INFO_IBITMAP_CORRUPT after it's inode
    bitmap buffer_head was successfully verified, then __ext4_new_inode()
    will get a valid inode_bitmap_bh of a corrupted group from
    ext4_read_inode_bitmap() in which case inode_bitmap_bh misses a release.
    Hnadle "IS_ERR(inode_bitmap_bh)" and group corruption separately like
    how ext4_free_inode() does to avoid buffer_head leak.
    
    Fixes: 9008a58e5dce ("ext4: make the bitmap read routines return real error codes")
    Signed-off-by: Kemeng Shi <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: check stripe size compatibility on remount as well [+ + +]
Author: Ojaswin Mujoo <[email protected]>
Date:   Fri Aug 30 12:50:57 2024 +0530

    ext4: check stripe size compatibility on remount as well
    
    [ Upstream commit ee85e0938aa8f9846d21e4d302c3cf6a2a75110d ]
    
    We disable stripe size in __ext4_fill_super if it is not a multiple of
    the cluster ratio however this check is missed when trying to remount.
    This can leave us with cases where stripe < cluster_ratio after
    remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some
    unforeseen bugs like divide by 0.
    
    Fix that by adding the check in remount path as well.
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Reviewed-by: Kemeng Shi <[email protected]>
    Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
    Fixes: c3defd99d58c ("ext4: treat stripe in block unit")
    Signed-off-by: Ojaswin Mujoo <[email protected]>
    Link: https://patch.msgid.link/3a493bb503c3598e25dcfbed2936bb2dff3fece7.1725002410.git.ojaswin@linux.ibm.com
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard [+ + +]
Author: yangerkun <[email protected]>
Date:   Sat Aug 17 16:55:10 2024 +0800

    ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard
    
    [ Upstream commit 20cee68f5b44fdc2942d20f3172a262ec247b117 ]
    
    Commit 3d56b8d2c74c ("ext4: Speed up FITRIM by recording flags in
    ext4_group_info") speed up fstrim by skipping trim trimmed group. We
    also has the chance to clear trimmed once there exists some block free
    for this group(mount without discard), and the next trim for this group
    will work well too.
    
    For mount with discard, we will issue dicard when we free blocks, so
    leave trimmed flag keep alive to skip useless trim trigger from
    userspace seems reasonable. But for some case like ext4 build on
    dm-thinpool(ext4 blocksize 4K, pool blocksize 128K), discard from ext4
    maybe unaligned for dm thinpool, and thinpool will just finish this
    discard(see process_discard_bio when begein equals to end) without
    actually process discard. For this case, trim from userspace can really
    help us to free some thinpool block.
    
    So convert to clear trimmed flag for all case no matter mounted with
    discard or not.
    
    Fixes: 3d56b8d2c74c ("ext4: Speed up FITRIM by recording flags in ext4_group_info")
    Signed-off-by: yangerkun <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: return error on ext4_find_inline_entry [+ + +]
Author: Thadeu Lima de Souza Cascardo <[email protected]>
Date:   Wed Aug 21 12:23:22 2024 -0300

    ext4: return error on ext4_find_inline_entry
    
    [ Upstream commit 4d231b91a944f3cab355fce65af5871fb5d7735b ]
    
    In case of errors when reading an inode from disk or traversing inline
    directory entries, return an error-encoded ERR_PTR instead of returning
    NULL. ext4_find_inline_entry only caller, __ext4_find_entry already returns
    such encoded errors.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Stable-dep-of: c6b72f5d82b1 ("ext4: avoid OOB when system.data xattr changes underneath the filesystem")
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: atomic: fix to avoid racing w/ GC [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Jun 25 11:13:48 2024 +0800

    f2fs: atomic: fix to avoid racing w/ GC
    
    [ Upstream commit 1a0bd289a5db1df8df8fab949633a0b8d3f235ee ]
    
    Case #1:
    SQLite App              GC Thread               Kworker         Shrinker
    - f2fs_ioc_start_atomic_write
    
    - f2fs_ioc_commit_atomic_write
     - f2fs_commit_atomic_write
      - filemap_write_and_wait_range
      : write atomic_file's data to cow_inode
                                                                    echo 3 > drop_caches
                                                                    to drop atomic_file's
                                                                    cache.
                            - f2fs_gc
                             - gc_data_segment
                              - move_data_page
                               - set_page_dirty
    
                                                    - writepages
                                                     - f2fs_do_write_data_page
                                                     : overwrite atomic_file's data
                                                       to cow_inode
      - f2fs_down_write(&fi->i_gc_rwsem[WRITE])
      - __f2fs_commit_atomic_write
      - f2fs_up_write(&fi->i_gc_rwsem[WRITE])
    
    Case #2:
    SQLite App              GC Thread               Kworker
    - f2fs_ioc_start_atomic_write
    
                                                    - __writeback_single_inode
                                                     - do_writepages
                                                      - f2fs_write_cache_pages
                                                       - f2fs_write_single_data_page
                                                        - f2fs_do_write_data_page
                                                        : write atomic_file's data to cow_inode
                            - f2fs_gc
                             - gc_data_segment
                              - move_data_page
                               - set_page_dirty
    
                                                    - writepages
                                                     - f2fs_do_write_data_page
                                                     : overwrite atomic_file's data to cow_inode
    - f2fs_ioc_commit_atomic_write
    
    In above cases racing in between atomic_write and GC, previous
    data in atomic_file may be overwrited to cow_file, result in
    data corruption.
    
    This patch introduces PAGE_PRIVATE_ATOMIC_WRITE bit flag in page.private,
    and use it to indicate that there is last dirty data in atomic file,
    and the data should be writebacked into cow_file, if the flag is not
    tagged in page, we should never write data across files.
    
    Fixes: 3db1de0e582c ("f2fs: change the current atomic write way")
    Cc: Daeho Jeong <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Aug 7 18:24:35 2024 +0800

    f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation
    
    [ Upstream commit ebd3309aec6271c4616573b0cb83ea25e623070a ]
    
    We should always truncate pagecache while truncating on-disk data.
    
    Fixes: a46bebd502fe ("f2fs: synchronize atomic write aborts")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: avoid potential int overflow in sanity_check_area_boundary() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jul 24 10:51:58 2024 -0700

    f2fs: avoid potential int overflow in sanity_check_area_boundary()
    
    commit 50438dbc483ca6a133d2bce9d5d6747bcee38371 upstream.
    
    While calculating the end addresses of main area and segment 0, u32
    may be not enough to hold the result without the danger of int
    overflow.
    
    Just in case, play it safe and cast one of the operands to a
    wider type (u64).
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: fd694733d523 ("f2fs: cover large section in sanity check of super")
    Cc: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: clean up w/ dotdot_name [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Nov 16 14:25:54 2023 +0800

    f2fs: clean up w/ dotdot_name
    
    [ Upstream commit ff6584ac2c4b4ee8e1fca20bffaaa387d8fe2974 ]
    
    Just cleanup, no logic changes.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: 884ee6dc85b9 ("f2fs: get rid of online repaire on corrupted directory")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: do sanity check on cluster when CONFIG_F2FS_CHECK_FS is on [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Aug 28 22:04:16 2023 +0800

    f2fs: compress: do sanity check on cluster when CONFIG_F2FS_CHECK_FS is on
    
    [ Upstream commit 2aaea533bf063ed3b442df5fe5f6abfc538054c9 ]
    
    This patch covers sanity check logic on cluster w/ CONFIG_F2FS_CHECK_FS,
    otherwise, there will be performance regression while querying cluster
    mapping info.
    
    Callers of f2fs_is_compressed_cluster() only care about whether cluster
    is compressed or not, rather than # of valid blocks in compressed cluster,
    so, let's adjust f2fs_is_compressed_cluster()'s logic according to
    caller's requirement.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: f785cec298c9 ("f2fs: compress: don't redirty sparse cluster during {,de}compress")
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: compress: don't redirty sparse cluster during {,de}compress [+ + +]
Author: Yeongjin Gil <[email protected]>
Date:   Mon Aug 19 17:34:30 2024 +0900

    f2fs: compress: don't redirty sparse cluster during {,de}compress
    
    [ Upstream commit f785cec298c95d00058560c0715233294a04b8f3 ]
    
    In f2fs_do_write_data_page, when the data block is NULL_ADDR, it skips
    writepage considering that it has been already truncated.
    This results in an infinite loop as the PAGECACHE_TAG_TOWRITE tag is not
    cleared during the writeback process for a compressed file including
    NULL_ADDR in compress_mode=user.
    
    This is the reproduction process:
    
    1. dd if=/dev/zero bs=4096 count=1024 seek=1024 of=testfile
    2. f2fs_io compress testfile
    3. dd if=/dev/zero bs=4096 count=1 conv=notrunc of=testfile
    4. f2fs_io decompress testfile
    
    To prevent the problem, let's check whether the cluster is fully
    allocated before redirty its pages.
    
    Fixes: 5fdb322ff2c2 ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE")
    Reviewed-by: Sungjong Seo <[email protected]>
    Reviewed-by: Sunmin Jeong <[email protected]>
    Tested-by: Jaewook Kim <[email protected]>
    Signed-off-by: Yeongjin Gil <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: Create COW inode from parent dentry for atomic write [+ + +]
Author: Yeongjin Gil <[email protected]>
Date:   Tue Aug 13 16:32:44 2024 +0900

    f2fs: Create COW inode from parent dentry for atomic write
    
    [ Upstream commit 8c1b787938fd86bab27a1492fa887408c75fec2b ]
    
    The i_pino in f2fs_inode_info has the previous parent's i_ino when inode
    was renamed, which may cause f2fs_ioc_start_atomic_write to fail.
    If file_wrong_pino is true and i_nlink is 1, then to find a valid pino,
    we should refer to the dentry from inode.
    
    To resolve this issue, let's get parent inode using parent dentry
    directly.
    
    Fixes: 3db1de0e582c ("f2fs: change the current atomic write way")
    Reviewed-by: Sungjong Seo <[email protected]>
    Reviewed-by: Sunmin Jeong <[email protected]>
    Signed-off-by: Yeongjin Gil <[email protected]>
    Reviewed-by: Daeho Jeong <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix several potential integer overflows in file offsets [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jul 24 10:28:38 2024 -0700

    f2fs: fix several potential integer overflows in file offsets
    
    commit 1cade98cf6415897bf9342ee451cc5b40b58c638 upstream.
    
    When dealing with large extents and calculating file offsets by
    summing up according extent offsets and lengths of unsigned int type,
    one may encounter possible integer overflow if the values are
    big enough.
    
    Prevent this from happening by expanding one of the addends to
    (pgoff_t) type.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: d323d005ac4a ("f2fs: support file defragment")
    Cc: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: fix to avoid racing in between read and OPU dio write [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Jun 27 15:15:21 2024 +0800

    f2fs: fix to avoid racing in between read and OPU dio write
    
    [ Upstream commit 0cac51185e65dc2a20686184e02f3cafc99eb202 ]
    
    If lfs mode is on, buffered read may race w/ OPU dio write as below,
    it may cause buffered read hits unwritten data unexpectly, and for
    dio read, the race condition exists as well.
    
    Thread A                        Thread B
    - f2fs_file_write_iter
     - f2fs_dio_write_iter
      - __iomap_dio_rw
       - f2fs_iomap_begin
        - f2fs_map_blocks
         - __allocate_data_block
          - allocated blkaddr #x
           - iomap_dio_submit_bio
                                    - f2fs_file_read_iter
                                     - filemap_read
                                      - f2fs_read_data_folio
                                       - f2fs_mpage_readpages
                                        - f2fs_map_blocks
                                         : get blkaddr #x
                                        - f2fs_submit_read_bio
                                    IRQ
                                    - f2fs_read_end_io
                                     : read IO on blkaddr #x complete
    IRQ
    - iomap_dio_bio_end_io
     : direct write IO on blkaddr #x complete
    
    In LFS mode, if there is inflight dio, let's wait for its completion,
    this policy won't cover all race cases, however it is a tradeoff which
    avoids abusing lock around IO paths.
    
    Fixes: f847c699cff3 ("f2fs: allow out-place-update for direct IO in LFS mode")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Jul 30 09:08:55 2024 +0800

    f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()
    
    [ Upstream commit c7f114d864ac91515bb07ac271e9824a20f5ed95 ]
    
    syzbot reports a f2fs bug as below:
    
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
     print_report+0xe8/0x550 mm/kasan/report.c:491
     kasan_report+0x143/0x180 mm/kasan/report.c:601
     kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
     instrument_atomic_read_write include/linux/instrumented.h:96 [inline]
     atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]
     __refcount_add include/linux/refcount.h:184 [inline]
     __refcount_inc include/linux/refcount.h:241 [inline]
     refcount_inc include/linux/refcount.h:258 [inline]
     get_task_struct include/linux/sched/task.h:118 [inline]
     kthread_stop+0xca/0x630 kernel/kthread.c:704
     f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210
     f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283
     f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]
     __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    The root cause is below race condition, it may cause use-after-free
    issue in sbi->gc_th pointer.
    
    - remount
     - f2fs_remount
      - f2fs_stop_gc_thread
       - kfree(gc_th)
                                    - f2fs_ioc_shutdown
                                     - f2fs_do_shutdown
                                      - f2fs_stop_gc_thread
                                       - kthread_stop(gc_th->f2fs_gc_task)
       : sbi->gc_thread = NULL;
    
    We will call f2fs_do_shutdown() in two paths:
    - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore
    for fixing.
    - for f2fs_shutdown() path, it's safe since caller has already grabbed
    sb->s_umount semaphore.
    
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/linux-f2fs-devel/[email protected]
    Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to check atomic_file in f2fs ioctl interfaces [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Sep 4 11:20:47 2024 +0800

    f2fs: fix to check atomic_file in f2fs ioctl interfaces
    
    commit bfe5c02654261bfb8bd9cb174a67f3279ea99e58 upstream.
    
    Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(),
    f2fs_move_file_range(), and f2fs_defragment_range() missed to
    check atomic_write status, which may cause potential race issue,
    fix it.
    
    Cc: [email protected]
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue Sep 10 11:07:13 2024 +0800

    f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()
    
    [ Upstream commit 930c6ab93492c4b15436524e704950b364b2930c ]
    
    syzbot reports a f2fs bug as below:
    
    ------------[ cut here ]------------
    WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
    CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
    Workqueue: events destroy_super_work
    RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
    Call Trace:
     percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
     destroy_super_work+0xec/0x130 fs/super.c:282
     process_one_work kernel/workqueue.c:3231 [inline]
     process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
     worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
     kthread+0x2f0/0x390 kernel/kthread.c:389
     ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
    
    As Christian Brauner pointed out [1]: the root cause is f2fs sets
    SB_RDONLY flag in internal function, rather than setting the flag
    covered w/ sb->s_umount semaphore via remount procedure, then below
    race condition causes this bug:
    
    - freeze_super()
     - sb_wait_write(sb, SB_FREEZE_WRITE)
     - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
     - sb_wait_write(sb, SB_FREEZE_FS)
                                            - f2fs_handle_critical_error
                                             - sb->s_flags |= SB_RDONLY
    - thaw_super
     - thaw_super_locked
      - sb_rdonly() is true, so it skips
        sb_freeze_unlock(sb, SB_FREEZE_FS)
      - deactivate_locked_super
    
    Since f2fs has almost the same logic as ext4 [2] when handling critical
    error in filesystem if it mounts w/ errors=remount-ro option:
    - set CP_ERROR_FLAG flag which indicates filesystem is stopped
    - record errors to superblock
    - set SB_RDONLY falg
    Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the
    flag and stop any further updates on filesystem. So, it is safe to not
    set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3].
    
    [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner
    [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3
    [3] https://lore.kernel.org/linux-ext4/[email protected]
    
    Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]/
    Cc: Jan Kara <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Reviewed-by: Christian Brauner <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: fix to wait page writeback before setting gcing flag [+ + +]
Author: Chao Yu <[email protected]>
Date:   Mon Aug 12 22:12:42 2024 +0800

    f2fs: fix to wait page writeback before setting gcing flag
    
    [ Upstream commit a4d7f2b3238fd5f76b9e6434a0bd5d2e29049cff ]
    
    Soft IRQ                                Thread
    - f2fs_write_end_io
                                            - f2fs_defragment_range
                                             - set_page_private_gcing
     - type = WB_DATA_TYPE(page, false);
     : assign type w/ F2FS_WB_CP_DATA
     due to page_private_gcing() is true
      - dec_page_count() w/ wrong type
      - end_page_writeback()
    
    Value of F2FS_WB_CP_DATA reference count may become negative under above
    race condition, the root cause is we missed to wait page writeback before
    setting gcing page private flag, let's fix it.
    
    Fixes: 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment")
    Fixes: 4961acdd65c9 ("f2fs: fix to tag gcing flag on page during block migration")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: get rid of online repaire on corrupted directory [+ + +]
Author: Chao Yu <[email protected]>
Date:   Fri Sep 6 14:27:24 2024 +0800

    f2fs: get rid of online repaire on corrupted directory
    
    [ Upstream commit 884ee6dc85b959bc152f15bca80c30f06069e6c4 ]
    
    syzbot reports a f2fs bug as below:
    
    kernel BUG at fs/f2fs/inode.c:896!
    RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
    Call Trace:
     evict+0x532/0x950 fs/inode.c:704
     dispose_list fs/inode.c:747 [inline]
     evict_inodes+0x5f9/0x690 fs/inode.c:797
     generic_shutdown_super+0x9d/0x2d0 fs/super.c:627
     kill_block_super+0x44/0x90 fs/super.c:1696
     kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898
     deactivate_locked_super+0xc4/0x130 fs/super.c:473
     cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373
     task_work_run+0x24f/0x310 kernel/task_work.c:228
     ptrace_notify+0x2d2/0x380 kernel/signal.c:2402
     ptrace_report_syscall include/linux/ptrace.h:415 [inline]
     ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]
     syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173
     syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]
     __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]
     syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218
     do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896
    
    Online repaire on corrupted directory in f2fs_lookup() can generate
    dirty data/meta while racing w/ readonly remount, it may leave dirty
    inode after filesystem becomes readonly, however, checkpoint() will
    skips flushing dirty inode in a state of readonly mode, result in
    above panic.
    
    Let's get rid of online repaire in f2fs_lookup(), and leave the work
    to fsck.f2fs.
    
    Fixes: 510022a85839 ("f2fs: add F2FS_INLINE_DOTS to recover missing dot dentries")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: prevent atomic file from being dirtied before commit [+ + +]
Author: Daeho Jeong <[email protected]>
Date:   Wed Sep 4 08:33:06 2024 -0700

    f2fs: prevent atomic file from being dirtied before commit
    
    [ Upstream commit fccaa81de87e80b1809906f7e438e5766fbdc172 ]
    
    Keep atomic file clean while updating and make it dirtied during commit
    in order to avoid unnecessary and excessive inode updates in the previous
    fix.
    
    Fixes: 4bf78322346f ("f2fs: mark inode dirty for FI_ATOMIC_COMMITTED flag")
    Signed-off-by: Daeho Jeong <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: prevent possible int overflow in dir_block_index() [+ + +]
Author: Nikita Zhandarovich <[email protected]>
Date:   Wed Jul 24 10:05:44 2024 -0700

    f2fs: prevent possible int overflow in dir_block_index()
    
    commit 47f268f33dff4a5e31541a990dc09f116f80e61c upstream.
    
    The result of multiplication between values derived from functions
    dir_buckets() and bucket_blocks() *could* technically reach
    2^30 * 2^2 = 2^32.
    
    While unlikely to happen, it is prudent to ensure that it will not
    lead to integer overflow. Thus, use mul_u32_u32() as it's more
    appropriate to mitigate the issue.
    
    Found by Linux Verification Center (linuxtesting.org) with static
    analysis tool SVACE.
    
    Fixes: 3843154598a0 ("f2fs: introduce large directory support")
    Cc: [email protected]
    Signed-off-by: Nikita Zhandarovich <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: reduce expensive checkpoint trigger frequency [+ + +]
Author: Chao Yu <[email protected]>
Date:   Wed Jun 26 09:47:27 2024 +0800

    f2fs: reduce expensive checkpoint trigger frequency
    
    [ Upstream commit aaf8c0b9ae042494cb4585883b15c1332de77840 ]
    
    We may trigger high frequent checkpoint for below case:
    1. mkdir /mnt/dir1; set dir1 encrypted
    2. touch /mnt/file1; fsync /mnt/file1
    3. mkdir /mnt/dir2; set dir2 encrypted
    4. touch /mnt/file2; fsync /mnt/file2
    ...
    
    Although, newly created dir and file are not related, due to
    commit bbf156f7afa7 ("f2fs: fix lost xattrs of directories"), we will
    trigger checkpoint whenever fsync() comes after a new encrypted dir
    created.
    
    In order to avoid such performance regression issue, let's record an
    entry including directory's ino in global cache whenever we update
    directory's xattr data, and then triggerring checkpoint() only if
    xattr metadata of target file's parent was updated.
    
    This patch updates to cover below no encryption case as well:
    1) parent is checkpointed
    2) set_xattr(dir) w/ new xnid
    3) create(file)
    4) fsync(file)
    
    Fixes: bbf156f7afa7 ("f2fs: fix lost xattrs of directories")
    Reported-by: wangzijie <[email protected]>
    Reported-by: Zhiguo Niu <[email protected]>
    Tested-by: Zhiguo Niu <[email protected]>
    Reported-by: Yunlei He <[email protected]>
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

f2fs: Require FMODE_WRITE for atomic write ioctls [+ + +]
Author: Jann Horn <[email protected]>
Date:   Tue Aug 6 16:07:16 2024 +0200

    f2fs: Require FMODE_WRITE for atomic write ioctls
    
    commit 4f5a100f87f32cb65d4bb1ad282a08c92f6f591e upstream.
    
    The F2FS ioctls for starting and committing atomic writes check for
    inode_owner_or_capable(), but this does not give LSMs like SELinux or
    Landlock an opportunity to deny the write access - if the caller's FSUID
    matches the inode's UID, inode_owner_or_capable() immediately returns true.
    
    There are scenarios where LSMs want to deny a process the ability to write
    particular files, even files that the FSUID of the process owns; but this
    can currently partially be bypassed using atomic write ioctls in two ways:
    
     - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can
       truncate an inode to size 0
     - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert
       changes another process concurrently made to a file
    
    Fix it by requiring FMODE_WRITE for these operations, just like for
    F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these
    ioctls when intending to write into the file, that seems unlikely to break
    anything.
    
    Fixes: 88b88a667971 ("f2fs: support atomic writes")
    Cc: [email protected]
    Signed-off-by: Jann Horn <[email protected]>
    Reviewed-by: Chao Yu <[email protected]>
    Reviewed-by: Eric Biggers <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

f2fs: support .shutdown in f2fs_sops [+ + +]
Author: Chao Yu <[email protected]>
Date:   Thu Feb 29 22:38:38 2024 +0800

    f2fs: support .shutdown in f2fs_sops
    
    [ Upstream commit ee745e4736fbf33079d0d0808e1343c2280fd59a ]
    
    Support .shutdown callback in f2fs_sops, then, it can be called to
    shut down the file system when underlying block device is marked dead.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Stable-dep-of: c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()")
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: hpfb: Fix an error handling path in hpfb_dio_probe() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Aug 1 22:34:39 2024 +0200

    fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()
    
    [ Upstream commit aa578e897520f32ae12bec487f2474357d01ca9c ]
    
    If an error occurs after request_mem_region(), a corresponding
    release_mem_region() should be called, as already done in the remove
    function.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firewire: core: correct range of block for case of switch statement [+ + +]
Author: Takashi Sakamoto <[email protected]>
Date:   Sat Aug 10 16:04:03 2024 +0900

    firewire: core: correct range of block for case of switch statement
    
    [ Upstream commit ebb9d3ca8f7efc1b6a2f1750d1058eda444883d0 ]
    
    A commit d8527cab6c31 ("firewire: cdev: implement new event to notify
    response subaction with time stamp") adds an additional case,
    FW_CDEV_EVENT_RESPONSE2, into switch statement in complete_transaction().
    However, the range of block is beyond to the case label and reaches
    neibour default label.
    
    This commit corrects the range of block. Fortunately, it has few impacts
    in practice since the local variable in the scope under the label is not
    used in codes under default label.
    
    Fixes: d8527cab6c31 ("firewire: cdev: implement new event to notify response subaction with time stamp")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware: arm_scmi: Fix double free in OPTEE transport [+ + +]
Author: Cristian Marussi <[email protected]>
Date:   Mon Aug 12 18:33:32 2024 +0100

    firmware: arm_scmi: Fix double free in OPTEE transport
    
    [ Upstream commit e98dba934b2fc587eafb83f47ad64d9053b18ae0 ]
    
    Channels can be shared between protocols, avoid freeing the same channel
    descriptors twice when unloading the stack.
    
    Fixes: 5f90f189a052 ("firmware: arm_scmi: Add optee transport")
    Signed-off-by: Cristian Marussi <[email protected]>
    Tested-by: Peng Fan <[email protected]>  #i.MX95 19x19 EVK
    Reviewed-by: Peng Fan <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Sudeep Holla <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
firmware_loader: Block path traversal [+ + +]
Author: Jann Horn <[email protected]>
Date:   Wed Aug 28 01:45:48 2024 +0200

    firmware_loader: Block path traversal
    
    commit f0e5311aa8022107d63c54e2f03684ec097d1394 upstream.
    
    Most firmware names are hardcoded strings, or are constructed from fairly
    constrained format strings where the dynamic parts are just some hex
    numbers or such.
    
    However, there are a couple codepaths in the kernel where firmware file
    names contain string components that are passed through from a device or
    semi-privileged userspace; the ones I could find (not counting interfaces
    that require root privileges) are:
    
     - lpfc_sli4_request_firmware_update() seems to construct the firmware
       filename from "ModelName", a string that was previously parsed out of
       some descriptor ("Vital Product Data") in lpfc_fill_vpd()
     - nfp_net_fw_find() seems to construct a firmware filename from a model
       name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
       think parses some descriptor that was read from the device.
       (But this case likely isn't exploitable because the format string looks
       like "netronome/nic_%s", and there shouldn't be any *folders* starting
       with "netronome/nic_". The previous case was different because there,
       the "%s" is *at the start* of the format string.)
     - module_flash_fw_schedule() is reachable from the
       ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
       GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
       enough to pass the privilege check), and takes a userspace-provided
       firmware name.
       (But I think to reach this case, you need to have CAP_NET_ADMIN over a
       network namespace that a special kind of ethernet device is mapped into,
       so I think this is not a viable attack path in practice.)
    
    Fix it by rejecting any firmware names containing ".." path components.
    
    For what it's worth, I went looking and haven't found any USB device
    drivers that use the firmware loader dangerously.
    
    Cc: [email protected]
    Reviewed-by: Danilo Krummrich <[email protected]>
    Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem")
    Signed-off-by: Jann Horn <[email protected]>
    Acked-by: Luis Chamberlain <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs: Create a generic is_dot_dotdot() utility [+ + +]
Author: Chuck Lever <[email protected]>
Date:   Sat Dec 30 19:46:00 2023 -0500

    fs: Create a generic is_dot_dotdot() utility
    
    commit 42c3732fa8073717dd7d924472f1c0bc5b452fdc upstream.
    
    De-duplicate the same functionality in several places by hoisting
    the is_dot_dotdot() utility function into linux/fs.h.
    
    Suggested-by: Amir Goldstein <[email protected]>
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: Amir Goldstein <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fs: Fix file_set_fowner LSM hook inconsistencies [+ + +]
Author: Mickaël Salaün <[email protected]>
Date:   Wed Aug 21 11:56:05 2024 +0200

    fs: Fix file_set_fowner LSM hook inconsistencies
    
    commit 26f204380a3c182e5adf1a798db0724d6111b597 upstream.
    
    The fcntl's F_SETOWN command sets the process that handle SIGIO/SIGURG
    for the related file descriptor.  Before this change, the
    file_set_fowner LSM hook was always called, ignoring the VFS logic which
    may not actually change the process that handles SIGIO (e.g. TUN, TTY,
    dnotify), nor update the related UID/EUID.
    
    Moreover, because security_file_set_fowner() was called without lock
    (e.g. f_owner.lock), concurrent F_SETOWN commands could result to a race
    condition and inconsistent LSM states (e.g. SELinux's fown_sid) compared
    to struct fown_struct's UID/EUID.
    
    This change makes sure the LSM states are always in sync with the VFS
    state by moving the security_file_set_fowner() call close to the
    UID/EUID updates and using the same f_owner.lock .
    
    Rename f_modown() to __f_setown() to simplify code.
    
    Cc: [email protected]
    Cc: Al Viro <[email protected]>
    Cc: Casey Schaufler <[email protected]>
    Cc: Christian Brauner <[email protected]>
    Cc: James Morris <[email protected]>
    Cc: Jann Horn <[email protected]>
    Cc: Ondrej Mosnacek <[email protected]>
    Cc: Paul Moore <[email protected]>
    Cc: Serge E. Hallyn <[email protected]>
    Cc: Stephen Smalley <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Mickaël Salaün <[email protected]>
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: wacom: Do not warn about dropped packets for first packet [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Mon Sep 9 13:32:08 2024 -0700

    HID: wacom: Do not warn about dropped packets for first packet
    
    [ Upstream commit 84aecf2d251a3359bc78b7c8e58f54b9fc966e89 ]
    
    The driver currently assumes that the first sequence number it will see
    is going to be 0. This is not a realiable assumption and can break if,
    for example, the tablet has already been running for some time prior to
    the kernel driver connecting to the device. This commit initializes the
    expected sequence number to -1 and will only print the "Dropped" warning
    the it has been updated to a non-negative value.
    
    Signed-off-by: Jason Gerecke <[email protected]>
    Tested-by: Joshua Dickens <[email protected]>
    Fixes: 6d09085b38e5 ("HID: wacom: Adding Support for new usages")
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

HID: wacom: Support sequence numbers smaller than 16-bit [+ + +]
Author: Jason Gerecke <[email protected]>
Date:   Mon Sep 9 13:32:07 2024 -0700

    HID: wacom: Support sequence numbers smaller than 16-bit
    
    [ Upstream commit 359673ea3a203611b4f6d0f28922a4b9d2cfbcc8 ]
    
    The current dropped packet reporting assumes that all sequence numbers
    are 16 bits in length. This results in misleading "Dropped" messages if
    the hardware uses fewer bits. For example, if a tablet uses only 8 bits
    to store its sequence number, once it rolls over from 255 -> 0, the
    driver will still be expecting a packet "256". This patch adjusts the
    logic to reset the next expected packet to logical_minimum whenever
    it overflows beyond logical_maximum.
    
    Signed-off-by: Jason Gerecke <[email protected]>
    Tested-by: Joshua Dickens <[email protected]>
    Fixes: 6d09085b38e5 ("HID: wacom: Adding Support for new usages")
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwmon: (max16065) Fix alarm attributes [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Sun Jul 21 06:41:17 2024 -0700

    hwmon: (max16065) Fix alarm attributes
    
    [ Upstream commit 119abf7d1815f098f7f91ae7abc84324a19943d7 ]
    
    Chips reporting overcurrent alarms report it in the second alarm register.
    That means the second alarm register has to be read, even if the chip only
    supports 8 or fewer ADC channels.
    
    MAX16067 and MAX16068 report undervoltage and overvoltage alarms in
    separate registers. Fold register contents together to report both with
    the existing alarm attribute. This requires actually storing the chip type
    in struct max16065_data. Rename the variable 'chip' to match the variable
    name used in the probe function.
    
    Reviewed-by: Tzung-Bi Shih <[email protected]>
    Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (max16065) Fix overflows seen when writing limits [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Thu Jul 18 09:52:01 2024 -0700

    hwmon: (max16065) Fix overflows seen when writing limits
    
    [ Upstream commit 744ec4477b11c42e2c8de9eb8364675ae7a0bd81 ]
    
    Writing large limits resulted in overflows as reported by module tests.
    
    in0_lcrit: Suspected overflow: [max=5538, read 0, written 2147483647]
    in0_crit: Suspected overflow: [max=5538, read 0, written 2147483647]
    in0_min: Suspected overflow: [max=5538, read 0, written 2147483647]
    
    Fix the problem by clamping prior to multiplications and the use of
    DIV_ROUND_CLOSEST, and by using consistent variable types.
    
    Reviewed-by: Tzung-Bi Shih <[email protected]>
    Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles")
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (max16065) Remove use of i2c_match_id() [+ + +]
Author: Andrew Davis <[email protected]>
Date:   Wed Apr 3 15:36:21 2024 -0500

    hwmon: (max16065) Remove use of i2c_match_id()
    
    [ Upstream commit 5a71654b398e3471f0169c266a3587cf09e1200c ]
    
    The function i2c_match_id() is used to fetch the matching ID from
    the i2c_device_id table. This is often used to then retrieve the
    matching driver_data. This can be done in one step with the helper
    i2c_get_match_data().
    
    This helper has a couple other benefits:
     * It doesn't need the i2c_device_id passed in so we do not need
       to have that forward declared, allowing us to remove those or
       move the i2c_device_id table down to its more natural spot
       with the other module info.
     * It also checks for device match data, which allows for OF and
       ACPI based probing. That means we do not have to manually check
       those first and can remove those checks.
    
    Signed-off-by: Andrew Davis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Stable-dep-of: 119abf7d1815 ("hwmon: (max16065) Fix alarm attributes")
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (ntc_thermistor) fix module autoloading [+ + +]
Author: Yuntao Liu <[email protected]>
Date:   Thu Aug 15 08:30:21 2024 +0000

    hwmon: (ntc_thermistor) fix module autoloading
    
    [ Upstream commit b6964d66a07a9003868e428a956949e17ab44d7e ]
    
    Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
    based on the alias from of_device_id table.
    
    Fixes: 9e8269de100d ("hwmon: (ntc_thermistor) Add DT with IIO support to NTC thermistor driver")
    Signed-off-by: Yuntao Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Sat Aug 3 14:49:22 2024 +0800

    hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init
    
    commit d57e2f7cffd57fe2800332dec768ec1b67a4159f upstream.
    
    Add the missing clk_disable_unprepare() before return in
    bcm2835_rng_init().
    
    Fixes: e5f9f41d5e62 ("hwrng: bcm2835 - add reset support")
    Cc: <[email protected]>
    Signed-off-by: Gaosheng Cui <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Sat Aug 3 14:49:23 2024 +0800

    hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume
    
    commit 4b7acc85de14ee8a2236f54445dc635d47eceac0 upstream.
    
    Add the missing clk_disable_unprepare() before return in
    cctrng_resume().
    
    Fixes: a583ed310bb6 ("hwrng: cctrng - introduce Arm CryptoCell driver")
    Cc: <[email protected]>
    Signed-off-by: Gaosheng Cui <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

hwrng: mtk - Use devm_pm_runtime_enable [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Mon Aug 26 15:04:15 2024 +0800

    hwrng: mtk - Use devm_pm_runtime_enable
    
    commit 78cb66caa6ab5385ac2090f1aae5f3c19e08f522 upstream.
    
    Replace pm_runtime_enable with the devres-enabled version which
    can trigger pm_runtime_disable.
    
    Otherwise, the below appears during reload driver.
    
    mtk_rng 1020f000.rng: Unbalanced pm_runtime_enable!
    
    Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support")
    Cc: <[email protected]>
    Suggested-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Guoqing Jiang <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: aspeed: Update the stop sw state when the bus recovery occurs [+ + +]
Author: Tommy Huang <[email protected]>
Date:   Wed Sep 11 17:39:51 2024 +0800

    i2c: aspeed: Update the stop sw state when the bus recovery occurs
    
    commit 93701d3b84ac5f3ea07259d4ced405c53d757985 upstream.
    
    When the i2c bus recovery occurs, driver will send i2c stop command
    in the scl low condition. In this case the sw state will still keep
    original situation. Under multi-master usage, i2c bus recovery will
    be called when i2c transfer timeout occurs. Update the stop command
    calling with aspeed_i2c_do_stop function to update master_state.
    
    Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
    Cc: [email protected] # v4.13+
    Signed-off-by: Tommy Huang <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: isch: Add missed 'else' [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Wed Sep 11 18:39:14 2024 +0300

    i2c: isch: Add missed 'else'
    
    commit 1db4da55070d6a2754efeb3743f5312fc32f5961 upstream.
    
    In accordance with the existing comment and code analysis
    it is quite likely that there is a missed 'else' when adapter
    times out. Add it.
    
    Fixes: 5bc1200852c3 ("i2c: Add Intel SCH SMBus support")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Cc: <[email protected]> # v2.6.27+
    Signed-off-by: Andi Shyti <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
IB/core: Fix ib_cache_setup_one error flow cleanup [+ + +]
Author: Patrisious Haddad <[email protected]>
Date:   Mon Sep 2 13:36:33 2024 +0300

    IB/core: Fix ib_cache_setup_one error flow cleanup
    
    [ Upstream commit 1403c8b14765eab805377dd3b75e96ace8747aed ]
    
    When ib_cache_update return an error, we exit ib_cache_setup_one
    instantly with no proper cleanup, even though before this we had
    already successfully done gid_table_setup_one, that results in
    the kernel WARN below.
    
    Do proper cleanup using gid_table_cleanup_one before returning
    the err in order to fix the issue.
    
    WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0
    Modules linked in:
    CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    RIP: 0010:gid_table_release_one+0x181/0x1a0
    Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41
    RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527
    RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001
    RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631
    R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001
    R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001
    FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ? show_regs+0x94/0xa0
     ? __warn+0x9e/0x1c0
     ? gid_table_release_one+0x181/0x1a0
     ? report_bug+0x1f9/0x340
     ? gid_table_release_one+0x181/0x1a0
     ? handle_bug+0xa2/0x110
     ? exc_invalid_op+0x31/0xa0
     ? asm_exc_invalid_op+0x16/0x20
     ? __warn_printk+0xc7/0x180
     ? __warn_printk+0xd4/0x180
     ? gid_table_release_one+0x181/0x1a0
     ib_device_release+0x71/0xe0
     ? __pfx_ib_device_release+0x10/0x10
     device_release+0x44/0xd0
     kobject_put+0x135/0x3d0
     put_device+0x20/0x30
     rxe_net_add+0x7d/0xa0
     rxe_newlink+0xd7/0x190
     nldev_newlink+0x1b0/0x2a0
     ? __pfx_nldev_newlink+0x10/0x10
     rdma_nl_rcv_msg+0x1ad/0x2e0
     rdma_nl_rcv_skb.constprop.0+0x176/0x210
     netlink_unicast+0x2de/0x400
     netlink_sendmsg+0x306/0x660
     __sock_sendmsg+0x110/0x120
     ____sys_sendmsg+0x30e/0x390
     ___sys_sendmsg+0x9b/0xf0
     ? kstrtouint+0x6e/0xa0
     ? kstrtouint_from_user+0x7c/0xb0
     ? get_pid_task+0xb0/0xd0
     ? proc_fail_nth_write+0x5b/0x140
     ? __fget_light+0x9a/0x200
     ? preempt_count_add+0x47/0xa0
     __sys_sendmsg+0x61/0xd0
     do_syscall_64+0x50/0x110
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Fixes: 1901b91f9982 ("IB/core: Fix potential NULL pointer dereference in pkey cache")
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Maher Sanalla <[email protected]>
    Link: https://patch.msgid.link/79137687d829899b0b1c9835fcb4b258004c439a.1725273354.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
icmp: change the order of rate limits [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Thu Aug 29 14:46:39 2024 +0000

    icmp: change the order of rate limits
    
    commit 8c2bd38b95f75f3d2a08c93e35303e26d480d24e upstream.
    
    ICMP messages are ratelimited :
    
    After the blamed commits, the two rate limiters are applied in this order:
    
    1) host wide ratelimit (icmp_global_allow())
    
    2) Per destination ratelimit (inetpeer based)
    
    In order to avoid side-channels attacks, we need to apply
    the per destination check first.
    
    This patch makes the following change :
    
    1) icmp_global_allow() checks if the host wide limit is reached.
       But credits are not yet consumed. This is deferred to 3)
    
    2) The per destination limit is checked/updated.
       This might add a new node in inetpeer tree.
    
    3) icmp_global_consume() consumes tokens if prior operations succeeded.
    
    This means that host wide ratelimit is still effective
    in keeping inetpeer tree small even under DDOS.
    
    As a bonus, I removed icmp_global.lock as the fast path
    can use a lock-free operation.
    
    Fixes: c0303efeab73 ("net: reduce cycles spend on ICMP replies that gets rate limited")
    Fixes: 4cdf507d5452 ("icmp: add a global rate limitation")
    Reported-by: Keyu Man <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Cc: Jesper Dangaard Brouer <[email protected]>
    Cc: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iio: adc: ad7606: fix oversampling gpio array [+ + +]
Author: Guillaume Stols <[email protected]>
Date:   Tue Jul 2 17:34:10 2024 +0000

    iio: adc: ad7606: fix oversampling gpio array
    
    [ Upstream commit 8dc4594b54dbaaba40dc8884ad3d42083de39434 ]
    
    gpiod_set_array_value was misused here: the implementation relied on the
    assumption that an unsigned long was required for each gpio, while the
    function expects a bit array stored in "as much unsigned long as needed
    for storing one bit per GPIO", i.e it is using a bit field.
    
    This leaded to incorrect parameter passed to gpiod_set_array_value, that
    would set 1 value instead of 3.
    It also prevents to select the software mode correctly for the AD7606B.
    
    Fixes: d2a415c86c6b ("iio: adc: ad7606: Add support for AD7606B ADC")
    Fixes: 41f71e5e7daf ("staging: iio: adc: ad7606: Use find_closest() macro")
    Signed-off-by: Guillaume Stols <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: adc: ad7606: fix standby gpio state to match the documentation [+ + +]
Author: Guillaume Stols <[email protected]>
Date:   Tue Jul 2 17:34:11 2024 +0000

    iio: adc: ad7606: fix standby gpio state to match the documentation
    
    [ Upstream commit 059fe4f8bbdf5cad212e1aeeb3e8968c80b9ff3b ]
    
    The binding's documentation specifies that "As the line is active low, it
    should be marked GPIO_ACTIVE_LOW". However, in the driver, it was handled
    the opposite way. This commit sets the driver's behaviour in sync with the
    documentation
    
    Fixes: 722407a4e8c0 ("staging:iio:ad7606: Use GPIO descriptor API")
    Signed-off-by: Guillaume Stols <[email protected]>
    Reviewed-by: Nuno Sa <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: chemical: bme680: Fix read/write ops to device by adding mutexes [+ + +]
Author: Vasileios Amoiridis <[email protected]>
Date:   Mon Jun 10 01:38:12 2024 +0200

    iio: chemical: bme680: Fix read/write ops to device by adding mutexes
    
    [ Upstream commit 77641e5a477d428335cd094b88ac54e09ccb70f4 ]
    
    Add mutexes in the {read/write}_raw() functions of the device to guard the
    read/write of data from/to the device. This is necessary because for any
    operation other than temperature, multiple reads need to take place from
    the device. Even though regmap has a locking by itself, it won't protect us
    from multiple applications trying to read at the same time temperature and
    pressure since the pressure reading includes an internal temperature
    reading and there is nothing to ensure that this temperature+pressure
    reading will happen sequentially without any other operation interfering
    in the meantime.
    
    Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
    Signed-off-by: Vasileios Amoiridis <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: magnetometer: ak8975: Convert enum->pointer for data in the match tables [+ + +]
Author: Biju Das <[email protected]>
Date:   Fri Aug 18 08:55:56 2023 +0100

    iio: magnetometer: ak8975: Convert enum->pointer for data in the match tables
    
    [ Upstream commit 4f9ea93afde190a0f906ee624fc9a45cf784551b ]
    
    Convert enum->pointer for data in the match tables to simplify the probe()
    by replacing device_get_match_data() and i2c_client_get_device_id by
    i2c_get_match_data() as we have similar I2C, ACPI and DT matching table.
    
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Stable-dep-of: da6e3160df23 ("iio: magnetometer: ak8975: drop incorrect AK09116 compatible")
    Signed-off-by: Sasha Levin <[email protected]>

iio: magnetometer: ak8975: drop incorrect AK09116 compatible [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Tue Aug 6 07:30:15 2024 +0200

    iio: magnetometer: ak8975: drop incorrect AK09116 compatible
    
    [ Upstream commit da6e3160df230692bbd48a6d52318035f19595e2 ]
    
    All compatibles in this binding without prefixes were deprecated, so
    adding a new deprecated one after some time is not allowed, because it
    defies the core logic of deprecating things.
    
    Drop the AK09916 vendorless compatible.
    
    Fixes: 76e28aa97fa0 ("iio: magnetometer: ak8975: add AK09116 support")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iio: magnetometer: ak8975: Fix 'Unexpected device' error [+ + +]
Author: André Apitzsch <[email protected]>
Date:   Sun Oct 1 18:09:56 2023 +0200

    iio: magnetometer: ak8975: Fix 'Unexpected device' error
    
    commit 848f68c760ab1e14a9046ea6e45e3304ab9fa50b upstream.
    
    Explicity specify array indices to fix mapping between
    asahi_compass_chipset and ak_def_array.
    While at it, remove unneeded AKXXXX.
    
    Fixes: 4f9ea93afde1 ("iio: magnetometer: ak8975: Convert enum->pointer for data in the match tables")
    Signed-off-by: André Apitzsch <[email protected]>
    Reviewed-by: Biju Das <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Input: adp5588-keys - fix check on return code [+ + +]
Author: Nuno Sa <[email protected]>
Date:   Fri Sep 20 09:22:52 2024 +0200

    Input: adp5588-keys - fix check on return code
    
    commit eb017f4ea13b1a5ad7f4332279f2e4c67b44bdea upstream.
    
    During adp5588_setup(), we read all the events to clear the event FIFO.
    However, adp5588_read() just calls i2c_smbus_read_byte_data() which
    returns the byte read in case everything goes well. Hence, we need to
    explicitly check for a negative error code instead of checking for
    something different than 0.
    
    Fixes: e960309ce318 ("Input: adp5588-keys - bail out on returned error")
    Cc: [email protected]
    Signed-off-by: Nuno Sa <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line [+ + +]
Author: Werner Sembach <[email protected]>
Date:   Tue Sep 10 11:40:07 2024 +0200

    Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line
    
    commit 01eed86d50af9fab27d876fd677b86259ebe9de3 upstream.
    
    There might be devices out in the wild where the board name is GMxXGxx
    instead of GMxXGxX.
    
    Adding both to be on the safe side.
    
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table [+ + +]
Author: Werner Sembach <[email protected]>
Date:   Tue Sep 10 11:40:08 2024 +0200

    Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table
    
    commit 3870e2850b56306d1d1e435c5a1ccbccd7c59291 upstream.
    
    The Gen6 devices have the same problem and the same Solution as the Gen5
    ones.
    
    Some TongFang barebones have touchpad and/or keyboard issues after
    suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
    them have an external PS/2 port so this can safely be set for all of
    them.
    
    I'm not entirely sure if every device listed really needs all four quirks,
    but after testing and production use, no negative effects could be
    observed when setting all four.
    
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table [+ + +]
Author: Werner Sembach <[email protected]>
Date:   Thu Sep 5 18:48:51 2024 +0200

    Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table
    
    commit e06edf96dea065dd1d9df695bf8b92784992333e upstream.
    
    Some TongFang barebones have touchpad and/or keyboard issues after
    suspend, fixable with nomux + reset + noloop + nopnp. Luckily, none of
    them have an external PS/2 port so this can safely be set for all of
    them.
    
    I'm not entirely sure if every device listed really needs all four quirks,
    but after testing and production use, no negative effects could be
    observed when setting all four.
    
    Signed-off-by: Werner Sembach <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Input: ilitek_ts_i2c - add report id message validation [+ + +]
Author: Emanuele Ghidoli <[email protected]>
Date:   Mon Aug 5 10:55:11 2024 +0200

    Input: ilitek_ts_i2c - add report id message validation
    
    [ Upstream commit 208989744a6f01bed86968473312d4e650e600b3 ]
    
    Ensure that the touchscreen response has correct "report id" byte
    before processing the touch data and discard other messages.
    
    Fixes: 42370681bd46 ("Input: Add support for ILITEK Lego Series")
    Signed-off-by: Emanuele Ghidoli <[email protected]>
    Signed-off-by: Francesco Dolcini <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Input: ilitek_ts_i2c - avoid wrong input subsystem sync [+ + +]
Author: Emanuele Ghidoli <[email protected]>
Date:   Mon Aug 5 10:55:10 2024 +0200

    Input: ilitek_ts_i2c - avoid wrong input subsystem sync
    
    [ Upstream commit 7d0b18cd5dc7429917812963611d961fd93cb44d ]
    
    For different reasons i2c transaction may fail or report id in the
    message may be wrong. Avoid closing the frame in this case as it will
    result in all contacts being dropped, indicating that nothing is
    touching the screen anymore, while usually it is not the case.
    
    Fixes: 42370681bd46 ("Input: Add support for ILITEK Lego Series")
    Signed-off-by: Emanuele Ghidoli <[email protected]>
    Signed-off-by: Francesco Dolcini <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Torokhov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
interconnect: icc-clk: Add missed num_nodes initialization [+ + +]
Author: Kees Cook <[email protected]>
Date:   Tue Jul 16 14:48:23 2024 -0700

    interconnect: icc-clk: Add missed num_nodes initialization
    
    [ Upstream commit c801ed86840ec38b2a9bcafeee3d7c9e14c743f3 ]
    
    With the new __counted_by annotation, the "num_nodes" struct member must
    be set before accessing the "nodes" array. This initialization was done
    in other places where a new struct icc_onecell_data is allocated, but this
    case in icc_clk_register() was missed. Set "num_nodes" after allocation.
    
    Fixes: dd4904f3b924 ("interconnect: qcom: Annotate struct icc_onecell_data with __counted_by")
    Signed-off-by: Kees Cook <[email protected]>
    Reviewed-by: Gustavo A. R. Silva <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Georgi Djakov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/io-wq: do not allow pinning outside of cpuset [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Tue Sep 10 19:11:56 2024 +0200

    io_uring/io-wq: do not allow pinning outside of cpuset
    
    [ Upstream commit 0997aa5497c714edbb349ca366d28bd550ba3408 ]
    
    The io worker threads are userland threads that just never exit to the
    userland. By that, they are also assigned to a cgroup (the group of the
    creating task).
    
    When changing the affinity of the io_wq thread via syscall, we must only
    allow cpumasks within the limits defined by the cpuset controller of the
    cgroup (if enabled).
    
    Fixes: da64d6db3bd3 ("io_uring: One wqe per wq")
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

io_uring/io-wq: inherit cpuset of cgroup in io worker [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Tue Sep 10 19:11:57 2024 +0200

    io_uring/io-wq: inherit cpuset of cgroup in io worker
    
    [ Upstream commit 84eacf177faa605853c58e5b1c0d9544b88c16fd ]
    
    The io worker threads are userland threads that just never exit to the
    userland. By that, they are also assigned to a cgroup (the group of the
    creating task).
    
    When creating a new io worker, this worker should inherit the cpuset
    of the cgroup.
    
    Fixes: da64d6db3bd3 ("io_uring: One wqe per wq")
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
io_uring/sqpoll: do not allow pinning outside of cpuset [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Mon Sep 9 17:00:36 2024 +0200

    io_uring/sqpoll: do not allow pinning outside of cpuset
    
    commit f011c9cf04c06f16b24f583d313d3c012e589e50 upstream.
    
    The submit queue polling threads are userland threads that just never
    exit to the userland. When creating the thread with IORING_SETUP_SQ_AFF,
    the affinity of the poller thread is set to the cpu specified in
    sq_thread_cpu. However, this CPU can be outside of the cpuset defined
    by the cgroup cpuset controller. This violates the rules defined by the
    cpuset controller and is a potential issue for realtime applications.
    
    In b7ed6d8ffd6 we fixed the default affinity of the poller thread, in
    case no explicit pinning is required by inheriting the one of the
    creating task. In case of explicit pinning, the check is more
    complicated, as also a cpu outside of the parent cpumask is allowed.
    We implemented this by using cpuset_cpus_allowed (that has support for
    cgroup cpusets) and testing if the requested cpu is in the set.
    
    Fixes: 37d1e2e3642e ("io_uring: move SQPOLL thread io-wq forked worker")
    Cc: [email protected] # 6.1+
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/sqpoll: do not put cpumask on stack [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Mon Sep 16 13:11:50 2024 +0200

    io_uring/sqpoll: do not put cpumask on stack
    
    commit 7f44beadcc11adb98220556d2ddbe9c97aa6d42d upstream.
    
    Putting the cpumask on the stack is deprecated for a long time (since
    2d3854a37e8), as these can be big. Given that, change the on-stack
    allocation of allowed_mask to be dynamically allocated.
    
    Fixes: f011c9cf04c0 ("io_uring/sqpoll: do not allow pinning outside of cpuset")
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/sqpoll: retain test for whether the CPU is valid [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Mon Sep 16 02:58:06 2024 -0600

    io_uring/sqpoll: retain test for whether the CPU is valid
    
    commit a09c17240bdf2e9fa6d0591afa9448b59785f7d4 upstream.
    
    A recent commit ensured that SQPOLL cannot be setup with a CPU that
    isn't in the current tasks cpuset, but it also dropped testing whether
    the CPU is valid in the first place. Without that, if a task passes in
    a CPU value that is too high, the following KASAN splat can get
    triggered:
    
    BUG: KASAN: stack-out-of-bounds in io_sq_offload_create+0x858/0xaa4
    Read of size 8 at addr ffff800089bc7b90 by task wq-aff.t/1391
    
    CPU: 4 UID: 1000 PID: 1391 Comm: wq-aff.t Not tainted 6.11.0-rc7-00227-g371c468f4db6 #7080
    Hardware name: linux,dummy-virt (DT)
    Call trace:
     dump_backtrace.part.0+0xcc/0xe0
     show_stack+0x14/0x1c
     dump_stack_lvl+0x58/0x74
     print_report+0x16c/0x4c8
     kasan_report+0x9c/0xe4
     __asan_report_load8_noabort+0x1c/0x24
     io_sq_offload_create+0x858/0xaa4
     io_uring_setup+0x1394/0x17c4
     __arm64_sys_io_uring_setup+0x6c/0x180
     invoke_syscall+0x6c/0x260
     el0_svc_common.constprop.0+0x158/0x224
     do_el0_svc+0x3c/0x5c
     el0_svc+0x34/0x70
     el0t_64_sync_handler+0x118/0x124
     el0t_64_sync+0x168/0x16c
    
    The buggy address belongs to stack of task wq-aff.t/1391
     and is located at offset 48 in frame:
     io_sq_offload_create+0x0/0xaa4
    
    This frame has 1 object:
     [32, 40) 'allowed_mask'
    
    The buggy address belongs to the virtual mapping at
     [ffff800089bc0000, ffff800089bc9000) created by:
     kernel_clone+0x124/0x7e0
    
    The buggy address belongs to the physical page:
    page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0000d740af80 pfn:0x11740a
    memcg:ffff0000c2706f02
    flags: 0xbffe00000000000(node=0|zone=2|lastcpupid=0x1fff)
    raw: 0bffe00000000000 0000000000000000 dead000000000122 0000000000000000
    raw: ffff0000d740af80 0000000000000000 00000001ffffffff ffff0000c2706f02
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff800089bc7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff800089bc7b00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
    >ffff800089bc7b80: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                             ^
     ffff800089bc7c00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
     ffff800089bc7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Fixes: f011c9cf04c0 ("io_uring/sqpoll: do not allow pinning outside of cpuset")
    Tested-by: Felix Moessbauer <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Wed Sep 18 11:58:19 2024 -0600

    io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL
    
    commit 04beb6e0e08c30c6f845f50afb7d7953603d7a6f upstream.
    
    If some part of the kernel adds task_work that needs executing, in terms
    of signaling it'll generally use TWA_SIGNAL or TWA_RESUME. Those two
    directly translate to TIF_NOTIFY_SIGNAL or TIF_NOTIFY_RESUME, and can
    be used for a variety of use case outside of task_work.
    
    However, io_cqring_wait_schedule() only tests explicitly for
    TIF_NOTIFY_SIGNAL. This means it can miss if task_work got added for
    the task, but used a different kind of signaling mechanism (or none at
    all). Normally this doesn't matter as any task_work will be run once
    the task exits to userspace, except if:
    
    1) The ring is setup with DEFER_TASKRUN
    2) The local work item may generate normal task_work
    
    For condition 2, this can happen when closing a file and it's the final
    put of that file, for example. This can cause stalls where a task is
    waiting to make progress inside io_cqring_wait(), but there's nothing else
    that will wake it up. Hence change the "should we schedule or loop around"
    check to check for the presence of task_work explicitly, rather than just
    TIF_NOTIFY_SIGNAL as the mechanism. While in there, also change the
    ordering of what type of task_work first in terms of ordering, to both
    make it consistent with other task_work runs in io_uring, but also to
    better handle the case of defer task_work generating normal task_work,
    like in the above example.
    
    Reported-by: Jan Hendrik Farr <[email protected]>
    Link: https://github.com/axboe/liburing/issues/1235
    Cc: [email protected]
    Fixes: 846072f16eed ("io_uring: mimimise io_cqring_wait_schedule")
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iommu/amd: Do not set the D bit on AMD v2 table entries [+ + +]
Author: Jason Gunthorpe <[email protected]>
Date:   Thu Aug 29 21:06:23 2024 -0300

    iommu/amd: Do not set the D bit on AMD v2 table entries
    
    [ Upstream commit 2910a7fa1be090fc7637cef0b2e70bcd15bf5469 ]
    
    The manual says that bit 6 is IGN for all Page-Table Base Address
    pointers, don't set it.
    
    Fixes: aaac38f61487 ("iommu/amd: Initial support for AMD IOMMU v2 page table")
    Reviewed-by: Vasant Hegde <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Joerg Roedel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660 [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Sat Sep 7 21:48:12 2024 +0300

    iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660
    
    [ Upstream commit 19eb465c969f3d6ed1b98506d3e470e863b41e16 ]
    
    The Qualcomm SDM630 / SDM660 platform requires the same kind of
    workaround as MSM8998: some IOMMUs have context banks reserved by
    firmware / TZ, touching those banks resets the board.
    
    Apply the num_context_bank workaround to those two SMMU devices in order
    to allow them to be used by Linux.
    
    Fixes: b812834b5329 ("iommu: arm-smmu-qcom: Add sdm630/msm8998 compatibles for qcom quirks")
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux [+ + +]
Author: Marc Gonzalez <[email protected]>
Date:   Tue Aug 20 15:27:19 2024 +0200

    iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux
    
    [ Upstream commit 3a8990b8a778219327c5f8ecf10b5d81377b925a ]
    
    On qcom msm8998, writing to the last context bank of lpass_q6_smmu
    (base address 0x05100000) produces a system freeze & reboot.
    
    The hardware/hypervisor reports 13 context banks for the LPASS SMMU
    on msm8998, but only the first 12 are accessible...
    Override the number of context banks
    
    [    2.546101] arm-smmu 5100000.iommu: probing hardware configuration...
    [    2.552439] arm-smmu 5100000.iommu: SMMUv2 with:
    [    2.558945] arm-smmu 5100000.iommu:  stage 1 translation
    [    2.563627] arm-smmu 5100000.iommu:  address translation ops
    [    2.568923] arm-smmu 5100000.iommu:  non-coherent table walk
    [    2.574566] arm-smmu 5100000.iommu:  (IDR0.CTTW overridden by FW configuration)
    [    2.580220] arm-smmu 5100000.iommu:  stream matching with 12 register groups
    [    2.587263] arm-smmu 5100000.iommu:  13 context banks (0 stage-2 only)
    [    2.614447] arm-smmu 5100000.iommu:  Supported page sizes: 0x63315000
    [    2.621358] arm-smmu 5100000.iommu:  Stage-1: 36-bit VA -> 36-bit IPA
    [    2.627772] arm-smmu 5100000.iommu:  preserved 0 boot mappings
    
    Specifically, the crashes occur here:
    
            qsmmu->bypass_cbndx = smmu->num_context_banks - 1;
            arm_smmu_cb_write(smmu, qsmmu->bypass_cbndx, ARM_SMMU_CB_SCTLR, 0);
    
    and here:
    
            arm_smmu_write_context_bank(smmu, i);
            arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_CB_FSR_FAULT);
    
    It is likely that FW reserves the last context bank for its own use,
    thus a simple work-around is: DON'T USE IT in Linux.
    
    If we decrease the number of context banks, last one will be "hidden".
    
    Signed-off-by: Marc Gonzalez <[email protected]>
    Reviewed-by: Caleb Connolly <[email protected]>
    Reviewed-by: Bjorn Andersson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Stable-dep-of: 19eb465c969f ("iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660")
    Signed-off-by: Sasha Levin <[email protected]>

iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages [+ + +]
Author: Konrad Dybcio <[email protected]>
Date:   Sat Aug 24 01:12:01 2024 +0200

    iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages
    
    [ Upstream commit 2d42d3ba443706c9164fa0bef4e5fd1c36bc1bd9 ]
    
    SDM845's Adreno SMMU is unique in that it actually advertizes support
    for 16K (and 32M) pages, which doesn't hold for newer SoCs.
    
    This however, seems either broken in the hardware implementation, the
    hypervisor middleware that abstracts the SMMU, or there's a bug in the
    Linux kernel somewhere down the line that nobody managed to track down.
    
    Booting SDM845 with 16K page sizes and drm/msm results in:
    
    *** gpu fault: ttbr0=0000000000000000 iova=000100000000c000 dir=READ
    type=TRANSLATION source=CP (0,0,0,0)
    
    right after loading the firmware. The GPU then starts spitting out
    illegal intstruction errors, as it's quite obvious that it got a
    bogus pointer.
    
    Moreover, it seems like this issue also concerns other implementations
    of SMMUv2 on Qualcomm SoCs, such as the one on SC7180.
    
    Hide 16K support on such instances to work around this.
    
    Reported-by: Sumit Semwal <[email protected]>
    Signed-off-by: Konrad Dybcio <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Stable-dep-of: 19eb465c969f ("iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660")
    Signed-off-by: Sasha Levin <[email protected]>

 
iommufd: Protect against overflow of ALIGN() during iova allocation [+ + +]
Author: Jason Gunthorpe <[email protected]>
Date:   Tue Aug 27 13:46:45 2024 -0300

    iommufd: Protect against overflow of ALIGN() during iova allocation
    
    commit 8f6887349b2f829a4121c518aeb064fc922714e4 upstream.
    
    Userspace can supply an iova and uptr such that the target iova alignment
    becomes really big and ALIGN() overflows which corrupts the selected area
    range during allocation. CONFIG_IOMMUFD_TEST can detect this:
    
       WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
       WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
       Modules linked in:
       CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0
       Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
       RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
       RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
       Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38
       RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293
       RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00
       RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000
       RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942
       R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010
       R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00
       FS:  000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        <TASK>
        iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274
        iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:907 [inline]
        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
        entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Cap the automatic alignment to the huge page size, which is probably a
    better idea overall. Huge automatic alignments can fragment and chew up
    the available IOVA space without any reason.
    
    Link: https://patch.msgid.link/r/[email protected]
    Cc: [email protected]
    Fixes: 51fe6141f0f6 ("iommufd: Data structure to provide IOVA to PFN mapping")
    Reviewed-by: Nicolin Chen <[email protected]>
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ipmi: docs: don't advertise deprecated sysfs entries [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Sun Sep 1 11:02:11 2024 +0200

    ipmi: docs: don't advertise deprecated sysfs entries
    
    [ Upstream commit 64dce81f8c373c681e62d5ffe0397c45a35d48a2 ]
    
    "i2c-adapter" class entries are deprecated since 2009. Switch to the
    proper location.
    
    Reported-by: Heiner Kallweit <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]
    Fixes: 259307074bfc ("ipmi: Add SMBus interface driver (SSIF)")
    Signed-off-by: Wolfram Sang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Corey Minyard <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 13 08:31:47 2024 +0000

    ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()
    
    [ Upstream commit 04ccecfa959d3b9ae7348780d8e379c6486176ac ]
    
    Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,
    as spotted by syzbot:
    
    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
     RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
     RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
    Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
    RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
    RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
    R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
    R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
    FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
     addrconf_notify+0x3cb/0x1020
      notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
      call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
      call_netdevice_notifiers net/core/dev.c:2046 [inline]
      unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
      unregister_netdevice_many net/core/dev.c:11414 [inline]
      unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
      unregister_netdevice include/linux/netdevice.h:3129 [inline]
      __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
      tun_detach drivers/net/tun.c:701 [inline]
      tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
      __fput+0x24a/0x8a0 fs/file_table.c:422
      task_work_run+0x24f/0x310 kernel/task_work.c:228
      exit_task_work include/linux/task_work.h:40 [inline]
      do_exit+0xa2f/0x27f0 kernel/exit.c:882
      do_group_exit+0x207/0x2c0 kernel/exit.c:1031
      __do_sys_exit_group kernel/exit.c:1042 [inline]
      __se_sys_exit_group kernel/exit.c:1040 [inline]
      __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
      x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f1acc77def9
    Code: Unable to access opcode bytes at 0x7f1acc77decf.
    RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
    RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
     </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
     RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
     RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
    Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
    RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
    RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
    RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
    R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
    R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
    FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: e332bc67cf5e ("ipv6: Don't call with rt6_uncached_list_flush_dev")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Acked-by: Martin KaFai Lau <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jfs: fix out-of-bounds in dbNextAG() and diAlloc() [+ + +]
Author: Jeongjun Park <[email protected]>
Date:   Mon Aug 19 13:05:46 2024 +0900

    jfs: fix out-of-bounds in dbNextAG() and diAlloc()
    
    [ Upstream commit e63866a475562810500ea7f784099bfe341e761a ]
    
    In dbNextAG() , there is no check for the case where bmp->db_numag is
    greater or same than MAXAG due to a polluted image, which causes an
    out-of-bounds. Therefore, a bounds check should be added in dbMount().
    
    And in dbNextAG(), a check for the case where agpref is greater than
    bmp->db_numag should be added, so an out-of-bounds exception should be
    prevented.
    
    Additionally, a check for the case where agno is greater or same than
    MAXAG should be added in diAlloc() to prevent out-of-bounds.
    
    Reported-by: Jeongjun Park <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jeongjun Park <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KEYS: prevent NULL pointer dereference in find_asymmetric_key() [+ + +]
Author: Roman Smirnov <[email protected]>
Date:   Tue Sep 17 18:54:53 2024 +0300

    KEYS: prevent NULL pointer dereference in find_asymmetric_key()
    
    commit 70fd1966c93bf3bfe3fe6d753eb3d83a76597eef upstream.
    
    In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2}
    arguments, the kernel will first emit WARN but then have an oops
    because id_2 gets dereferenced anyway.
    
    Add the missing id_2 check and move WARN_ON() to the final else branch
    to avoid duplicate NULL checks.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace static
    analysis tool.
    
    Cc: [email protected] # v5.17+
    Fixes: 7d30198ee24f ("keys: X.509 public key issuer lookup without AKID")
    Suggested-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Roman Smirnov <[email protected]>
    Reviewed-by: Sergey Shtylyov <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kselftest/arm64: Actually test SME vector length changes via sigreturn [+ + +]
Author: Mark Brown <[email protected]>
Date:   Thu Aug 29 18:20:09 2024 +0100

    kselftest/arm64: Actually test SME vector length changes via sigreturn
    
    [ Upstream commit 6f0315330af7a57c1c00587fdfb69c7778bf1c50 ]
    
    The test case for SME vector length changes via sigreturn use a bit too
    much cut'n'paste and only actually changed the SVE vector length in the
    test itself. Andre's recent factoring out of the initialisation code caused
    this to be exposed and the test to start failing. Fix the test to actually
    cover the thing it's supposed to test.
    
    Fixes: 4963aeb35a9e ("kselftest/arm64: signal: Add SME signal handling tests")
    Signed-off-by: Mark Brown <[email protected]>
    Reviewed-by: Andre Przywara <[email protected]>
    Tested-by: Andre Przywara <[email protected]>
    Link: https://lore.kernel.org/r/20240829-arm64-sme-signal-vl-change-test-v1-1-42d7534cb818@kernel.org
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

kselftest/arm64: signal: fix/refactor SVE vector length enumeration [+ + +]
Author: Andre Przywara <[email protected]>
Date:   Wed Aug 21 17:44:01 2024 +0100

    kselftest/arm64: signal: fix/refactor SVE vector length enumeration
    
    [ Upstream commit 5225b6562b9a7dc808d5a1e465aaf5e2ebb220cd ]
    
    Currently a number of SVE/SME related tests have almost identical
    functions to enumerate all supported vector lengths. However over time
    the copy&pasted code has diverged, allowing some bugs to creep in:
    - fake_sigreturn_sme_change_vl reports a failure, not a SKIP if only
      one vector length is supported (but the SVE version is fine)
    - fake_sigreturn_sme_change_vl tries to set the SVE vector length, not
      the SME one (but the other SME tests are fine)
    - za_no_regs keeps iterating forever if only one vector length is
      supported (but za_regs is correct)
    
    Since those bugs seem to be mostly copy&paste ones, let's consolidate
    the enumeration loop into one shared function, and just call that from
    each test. That should fix the above bugs, and prevent similar issues
    from happening again.
    
    Fixes: 4963aeb35a9e ("kselftest/arm64: signal: Add SME signal handling tests")
    Signed-off-by: Andre Przywara <[email protected]>
    Reviewed-by: Mark Brown <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: allow write with FILE_APPEND_DATA [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue Sep 3 20:26:33 2024 +0900

    ksmbd: allow write with FILE_APPEND_DATA
    
    commit 2fb9b5dc80cabcee636a6ccd020740dd925b4580 upstream.
    
    Windows client write with FILE_APPEND_DATA when using git.
    ksmbd should allow write it with this flags.
    
    Z:\test>git commit -m "test"
    fatal: cannot update the ref 'HEAD': unable to append to
     '.git/logs/HEAD': Bad file descriptor
    
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Cc: [email protected] # v5.15+
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: handle caseless file creation [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Sun Sep 8 15:23:48 2024 +0900

    ksmbd: handle caseless file creation
    
    commit c5a709f08d40b1a082e44ffcde1aea4d2822ddd5 upstream.
    
    Ray Zhang reported ksmbd can not create file if parent filename is
    caseless.
    
    Y:\>mkdir A
    Y:\>echo 123 >a\b.txt
    The system cannot find the path specified.
    Y:\>echo 123 >A\b.txt
    
    This patch convert name obtained by caseless lookup to parent name.
    
    Cc: [email protected] # v5.15+
    Reported-by: Ray Zhang <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ksmbd: make __dir_empty() compatible with POSIX [+ + +]
Author: Hobin Woo <[email protected]>
Date:   Wed Sep 4 13:36:35 2024 +0900

    ksmbd: make __dir_empty() compatible with POSIX
    
    commit ca4974ca954561e79f8871d220bb08f14f64f57c upstream.
    
    Some file systems may not provide dot (.) and dot-dot (..) as they are
    optional in POSIX. ksmbd can misjudge emptiness of a directory in those
    file systems, since it assumes there are always at least two entries:
    dot and dot-dot.
    Just don't count dot and dot-dot.
    
    Cc: [email protected] # v6.1+
    Signed-off-by: Hobin Woo <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
kthread: fix task state in kthread worker if being frozen [+ + +]
Author: Chen Yu <[email protected]>
Date:   Tue Aug 27 19:23:08 2024 +0800

    kthread: fix task state in kthread worker if being frozen
    
    [ Upstream commit e16c7b07784f3fb03025939c4590b9a7c64970a7 ]
    
    When analyzing a kernel waring message, Peter pointed out that there is a
    race condition when the kworker is being frozen and falls into
    try_to_freeze() with TASK_INTERRUPTIBLE, which could trigger a
    might_sleep() warning in try_to_freeze().  Although the root cause is not
    related to freeze()[1], it is still worthy to fix this issue ahead.
    
    One possible race scenario:
    
            CPU 0                                           CPU 1
            -----                                           -----
    
            // kthread_worker_fn
            set_current_state(TASK_INTERRUPTIBLE);
                                                           suspend_freeze_processes()
                                                             freeze_processes
                                                               static_branch_inc(&freezer_active);
                                                             freeze_kernel_threads
                                                               pm_nosig_freezing = true;
            if (work) { //false
              __set_current_state(TASK_RUNNING);
    
            } else if (!freezing(current)) //false, been frozen
    
                          freezing():
                          if (static_branch_unlikely(&freezer_active))
                            if (pm_nosig_freezing)
                              return true;
              schedule()
            }
    
            // state is still TASK_INTERRUPTIBLE
            try_to_freeze()
              might_sleep() <--- warning
    
    Fix this by explicitly set the TASK_RUNNING before entering
    try_to_freeze().
    
    Link: https://lore.kernel.org/lkml/Zs2ZoAcUsZMX2B%2FI@chenyu5-mobl2/ [1]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: b56c0d8937e6 ("kthread: implement kthread_worker")
    Signed-off-by: Chen Yu <[email protected]>
    Suggested-by: Peter Zijlstra <[email protected]>
    Suggested-by: Andrew Morton <[email protected]>
    Cc: Andreas Gruenbacher <[email protected]>
    Cc: David Gow <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Mickaël Salaün <[email protected]>
    Cc: Tejun Heo <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer [+ + +]
Author: Snehal Koukuntla <[email protected]>
Date:   Mon Sep 9 18:01:54 2024 +0000

    KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer
    
    commit f26a525b77e040d584e967369af1e018d2d59112 upstream.
    
    When we share memory through FF-A and the description of the buffers
    exceeds the size of the mapped buffer, the fragmentation API is used.
    The fragmentation API allows specifying chunks of descriptors in subsequent
    FF-A fragment calls and no upper limit has been established for this.
    The entire memory region transferred is identified by a handle which can be
    used to reclaim the transferred memory.
    To be able to reclaim the memory, the description of the buffers has to fit
    in the ffa_desc_buf.
    Add a bounds check on the FF-A sharing path to prevent the memory reclaim
    from failing.
    
    Also do_ffa_mem_xfer() does not need __always_inline, except for the
    BUILD_BUG_ON() aspect, which gets moved to a macro.
    
    [maz: fixed the BUILD_BUG_ON() breakage with LLVM, thanks to Wei-Lin Chang
     for the timely report]
    
    Fixes: 634d90cf0ac65 ("KVM: arm64: Handle FFA_MEM_LEND calls from the host")
    Cc: [email protected]
    Reviewed-by: Sebastian Ene <[email protected]>
    Signed-off-by: Snehal Koukuntla <[email protected]>
    Reviewed-by: Oliver Upton <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Thu Aug 29 21:35:51 2024 -0700

    KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock
    
    commit 44d17459626052a2390457e550a12cb973506b2f upstream.
    
    Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock
    on x86 due to a chain of locks and SRCU synchronizations.  Translating the
    below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on
    CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the
    fairness of r/w semaphores).
    
        CPU0                     CPU1                     CPU2
    1   lock(&kvm->slots_lock);
    2                                                     lock(&vcpu->mutex);
    3                                                     lock(&kvm->srcu);
    4                            lock(cpu_hotplug_lock);
    5                            lock(kvm_lock);
    6                            lock(&kvm->slots_lock);
    7                                                     lock(cpu_hotplug_lock);
    8   sync(&kvm->srcu);
    
    Note, there are likely more potential deadlocks in KVM x86, e.g. the same
    pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with
    __kvmclock_cpufreq_notifier():
    
      cpuhp_cpufreq_online()
      |
      -> cpufreq_online()
         |
         -> cpufreq_gov_performance_limits()
            |
            -> __cpufreq_driver_target()
               |
               -> __target_index()
                  |
                  -> cpufreq_freq_transition_begin()
                     |
                     -> cpufreq_notify_transition()
                        |
                        -> ... __kvmclock_cpufreq_notifier()
    
    But, actually triggering such deadlocks is beyond rare due to the
    combination of dependencies and timings involved.  E.g. the cpufreq
    notifier is only used on older CPUs without a constant TSC, mucking with
    the NX hugepage mitigation while VMs are running is very uncommon, and
    doing so while also onlining/offlining a CPU (necessary to generate
    contention on cpu_hotplug_lock) would be even more unusual.
    
    The most robust solution to the general cpu_hotplug_lock issue is likely
    to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq
    notifier doesn't to take kvm_lock.  For now, settle for fixing the most
    blatant deadlock, as switching to an RCU-protected list is a much more
    involved change, but add a comment in locking.rst to call out that care
    needs to be taken when walking holding kvm_lock and walking vm_list.
    
      ======================================================
      WARNING: possible circular locking dependency detected
      6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S         O
      ------------------------------------------------------
      tee/35048 is trying to acquire lock:
      ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]
    
      but task is already holding lock:
      ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]
    
      which lock already depends on the new lock.
    
       the existing dependency chain (in reverse order) is:
    
      -> #3 (kvm_lock){+.+.}-{3:3}:
             __mutex_lock+0x6a/0xb40
             mutex_lock_nested+0x1f/0x30
             kvm_dev_ioctl+0x4fb/0xe50 [kvm]
             __se_sys_ioctl+0x7b/0xd0
             __x64_sys_ioctl+0x21/0x30
             x64_sys_call+0x15d0/0x2e60
             do_syscall_64+0x83/0x160
             entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
      -> #2 (cpu_hotplug_lock){++++}-{0:0}:
             cpus_read_lock+0x2e/0xb0
             static_key_slow_inc+0x16/0x30
             kvm_lapic_set_base+0x6a/0x1c0 [kvm]
             kvm_set_apic_base+0x8f/0xe0 [kvm]
             kvm_set_msr_common+0x9ae/0xf80 [kvm]
             vmx_set_msr+0xa54/0xbe0 [kvm_intel]
             __kvm_set_msr+0xb6/0x1a0 [kvm]
             kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]
             kvm_vcpu_ioctl+0x485/0x5b0 [kvm]
             __se_sys_ioctl+0x7b/0xd0
             __x64_sys_ioctl+0x21/0x30
             x64_sys_call+0x15d0/0x2e60
             do_syscall_64+0x83/0x160
             entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
      -> #1 (&kvm->srcu){.+.+}-{0:0}:
             __synchronize_srcu+0x44/0x1a0
             synchronize_srcu_expedited+0x21/0x30
             kvm_swap_active_memslots+0x110/0x1c0 [kvm]
             kvm_set_memslot+0x360/0x620 [kvm]
             __kvm_set_memory_region+0x27b/0x300 [kvm]
             kvm_vm_ioctl_set_memory_region+0x43/0x60 [kvm]
             kvm_vm_ioctl+0x295/0x650 [kvm]
             __se_sys_ioctl+0x7b/0xd0
             __x64_sys_ioctl+0x21/0x30
             x64_sys_call+0x15d0/0x2e60
             do_syscall_64+0x83/0x160
             entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
      -> #0 (&kvm->slots_lock){+.+.}-{3:3}:
             __lock_acquire+0x15ef/0x2e30
             lock_acquire+0xe0/0x260
             __mutex_lock+0x6a/0xb40
             mutex_lock_nested+0x1f/0x30
             set_nx_huge_pages+0x179/0x1e0 [kvm]
             param_attr_store+0x93/0x100
             module_attr_store+0x22/0x40
             sysfs_kf_write+0x81/0xb0
             kernfs_fop_write_iter+0x133/0x1d0
             vfs_write+0x28d/0x380
             ksys_write+0x70/0xe0
             __x64_sys_write+0x1f/0x30
             x64_sys_call+0x281b/0x2e60
             do_syscall_64+0x83/0x160
             entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Cc: Chao Gao <[email protected]>
    Fixes: 0bf50497f03b ("KVM: Drop kvm_count_lock and instead protect kvm_usage_count with kvm_lock")
    Cc: [email protected]
    Reviewed-by: Kai Huang <[email protected]>
    Acked-by: Kai Huang <[email protected]>
    Tested-by: Farrah Chen <[email protected]>
    Signed-off-by: Sean Christopherson <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Jul 19 16:50:58 2024 -0700

    KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits
    
    commit 71bf395a276f0578d19e0ae137a7d1d816d08e0e upstream.
    
    Inject a #GP on a WRMSR(ICR) that attempts to set any reserved bits that
    are must-be-zero on both Intel and AMD, i.e. any reserved bits other than
    the BUSY bit, which Intel ignores and basically says is undefined.
    
    KVM's xapic_state_test selftest has been fudging the bug since commit
    4b88b1a518b3 ("KVM: selftests: Enhance handling WRMSR ICR register in
    x2APIC mode"), which essentially removed the testcase instead of fixing
    the bug.
    
    WARN if the nodecode path triggers a #GP, as the CPU is supposed to check
    reserved bits for ICR when it's partially virtualized.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode() [+ + +]
Author: Sean Christopherson <[email protected]>
Date:   Fri Jul 19 16:50:59 2024 -0700

    KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()
    
    commit d33234342f8b468e719e05649fd26549fb37ef8a upstream.
    
    Hoist kvm_x2apic_icr_write() above kvm_apic_write_nodecode() so that a
    local helper to _read_ the x2APIC ICR can be added and used in the
    nodecode path without needing a forward declaration.
    
    No functional change intended.
    
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe() [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Sun Jul 21 17:19:03 2024 +0200

    leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()
    
    [ Upstream commit ffbf1fcb421429916a861cfc25dfe0c6387dda75 ]
    
    The current implementation accesses the `child` fwnode handle outside of
    fwnode_for_each_available_child_node() without incrementing its
    refcount. Add the missing call to `fwnode_handle_get(child)`.
    
    The cleanup process where `child` is accessed is not right either
    because a single call to `fwnode_handle_put()` is carried out in case of
    an error, ignoring unasigned nodes at the point when the error happens.
    Keep `child` inside of the first loop, and use the helper pointer that
    receives references via `fwnode_handle_get()` to handle the child nodes
    within the second loop.
    
    Moreover, the iterated nodes are direct children of the device node,
    and the `device_for_each_child_node()` macro accounts for child node
    availability. By restricting `child` to live within that loop, the
    scoped version of it can be used to simplify the error handling.
    
    `fwnode_for_each_available_child_node()` is meant to access the child
    nodes of an fwnode, and therefore not direct child nodes of the device
    node.
    
    Use `device_for_each_child_node_scoped()` to indicate device's direct
    child nodes.
    
    Fixes: 8325642d2757 ("leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://lore.kernel.org/r/20240721-device_for_each_child_node-available-v2-3-f33748fd8b2d@gmail.com
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

leds: leds-pca995x: Add support for NXP PCA9956B [+ + +]
Author: Pieterjan Camerlynck <[email protected]>
Date:   Thu Jul 11 14:49:51 2024 +0200

    leds: leds-pca995x: Add support for NXP PCA9956B
    
    [ Upstream commit 68d6520d2e76998cdea58f6dd8782de5ab5b28af ]
    
    Add support for PCA9956B chip, which belongs to the same family.
    
    This chip features 24 instead of 16 outputs, so add a chipdef struct to
    deal with the different register layouts.
    
    Reviewed-by: Marek Vasut <[email protected]>
    Signed-off-by: Pieterjan Camerlynck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Stable-dep-of: 82c5ada1f9d0 ("leds: pca995x: Fix device child node usage in pca995x_probe()")
    Signed-off-by: Sasha Levin <[email protected]>

leds: pca995x: Fix device child node usage in pca995x_probe() [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Wed Aug 7 15:37:03 2024 +0200

    leds: pca995x: Fix device child node usage in pca995x_probe()
    
    [ Upstream commit 82c5ada1f9d05902a4ccb926c7ce34e2fe699283 ]
    
    The current implementation accesses the `child` fwnode handle outside of
    device_for_each_child_node() without incrementing its refcount.
    
    Add the missing call to `fwnode_handle_get(child)`.
    
    The cleanup process where `child` is accessed is not right either
    because a single call to `fwnode_handle_put()` is carried out in case of
    an error, ignoring unasigned nodes at the point when the error happens.
    
    Keep `child` inside of the first loop, and use the helper pointer that
    receives references via `fwnode_handle_get()` to handle the child nodes
    within the second loop. Keeping `child` inside the first node has also
    the advantage that the scoped version of the loop can be used.
    
    Fixes: ee4e80b2962e ("leds: pca995x: Add support for PCA995X chips")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://lore.kernel.org/r/20240807-leds-pca995x-fix-fwnode-usage-v1-1-8057c84dc583@gmail.com
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

leds: pca995x: Use device_for_each_child_node() to access device child nodes [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Mon Aug 5 16:49:45 2024 +0200

    leds: pca995x: Use device_for_each_child_node() to access device child nodes
    
    [ Upstream commit 6eefd65ba6ae29ab801f6461e59c10f93dd496f8 ]
    
    The iterated nodes are direct children of the device node, and the
    `device_for_each_child_node()` macro accounts for child node
    availability.
    
    `fwnode_for_each_available_child_node()` is meant to access the child
    nodes of an fwnode, and therefore not direct child nodes of the device
    node.
    
    Use `device_for_each_child_node()` to indicate device's direct child
    nodes.
    
    Signed-off-by: Javier Carrasco <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/r/20240805-device_for_each_child_node-available-v3-2-48243a4aa5c0@gmail.com
    Signed-off-by: Lee Jones <[email protected]>
    Stable-dep-of: 82c5ada1f9d0 ("leds: pca995x: Fix device child node usage in pca995x_probe()")
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/bitmap: add bitmap_{read,write}() [+ + +]
Author: Syed Nayyar Waris <[email protected]>
Date:   Wed Mar 27 16:23:38 2024 +0100

    lib/bitmap: add bitmap_{read,write}()
    
    [ Upstream commit 63c15822b8dd02a2423cfd92232245ace3f7a11b ]
    
    The two new functions allow reading/writing values of length up to
    BITS_PER_LONG bits at arbitrary position in the bitmap.
    
    The code was taken from "bitops: Introduce the for_each_set_clump macro"
    by Syed Nayyar Waris with a number of changes and simplifications:
     - instead of using roundup(), which adds an unnecessary dependency
       on <linux/math.h>, we calculate space as BITS_PER_LONG-offset;
     - indentation is reduced by not using else-clauses (suggested by
       checkpatch for bitmap_get_value());
     - bitmap_get_value()/bitmap_set_value() are renamed to bitmap_read()
       and bitmap_write();
     - some redundant computations are omitted.
    
    Cc: Arnd Bergmann <[email protected]>
    Signed-off-by: Syed Nayyar Waris <[email protected]>
    Signed-off-by: William Breathitt Gray <[email protected]>
    Link: https://lore.kernel.org/lkml/fe12eedf3666f4af5138de0e70b67a07c7f40338.1592224129.git.syednwaris@gmail.com/
    Suggested-by: Yury Norov <[email protected]>
    Co-developed-by: Alexander Potapenko <[email protected]>
    Signed-off-by: Alexander Potapenko <[email protected]>
    Reviewed-by: Andy Shevchenko <[email protected]>
    Acked-by: Yury Norov <[email protected]>
    Signed-off-by: Yury Norov <[email protected]>
    Signed-off-by: Alexander Lobakin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 77b0b98bb743 ("btrfs: subpage: fix the bitmap dump which can cause bitmap corruption")
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/sbitmap: define swap_lock as raw_spinlock_t [+ + +]
Author: Ming Lei <[email protected]>
Date:   Thu Sep 19 10:17:09 2024 +0800

    lib/sbitmap: define swap_lock as raw_spinlock_t
    
    [ Upstream commit 65f666c6203600053478ce8e34a1db269a8701c9 ]
    
    When called from sbitmap_queue_get(), sbitmap_deferred_clear() may be run
    with preempt disabled. In RT kernel, spin_lock() can sleep, then warning
    of "BUG: sleeping function called from invalid context" can be triggered.
    
    Fix it by replacing it with raw_spin_lock.
    
    Cc: Yang Yang <[email protected]>
    Fixes: 72d04bdcf3f7 ("sbitmap: fix io hung due to race on sbitmap_word::cleared")
    Signed-off-by: Ming Lei <[email protected]>
    Reviewed-by: Yang Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib/xarray: introduce a new helper xas_get_order [+ + +]
Author: Kairui Song <[email protected]>
Date:   Wed Oct 2 05:06:24 2024 +0800

    lib/xarray: introduce a new helper xas_get_order
    
    commit a4864671ca0bf51c8e78242951741df52c06766f upstream.
    
    It can be used after xas_load to check the order of loaded entries.
    Compared to xa_get_order, it saves an XA_STATE and avoid a rewalk.
    
    Added new test for xas_get_order, to make the test work, we have to export
    xas_get_order with EXPORT_SYMBOL_GPL.
    
    Also fix a sparse warning by checking the slot value with xa_entry instead
    of accessing it directly, as suggested by Matthew Wilcox.
    
    [[email protected]: simplify comment, sparse warning fix, per Matthew Wilcox]
      Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Kairui Song <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 6758c1128ceb ("mm/filemap: optimize filemap folio adding")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.6.54 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Fri Oct 4 16:30:05 2024 +0200

    Linux 6.6.54
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Takeshi Ogasawara <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Harshit Mogalapalli <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Allen Pais <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Kexy Biscuit <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
lockdep: fix deadlock issue between lockdep and rcu [+ + +]
Author: Zhiguo Niu <[email protected]>
Date:   Thu Jun 20 22:54:34 2024 +0000

    lockdep: fix deadlock issue between lockdep and rcu
    
    commit a6f88ac32c6e63e69c595bfae220d8641704c9b7 upstream.
    
    There is a deadlock scenario between lockdep and rcu when
    rcu nocb feature is enabled, just as following call stack:
    
         rcuop/x
    -000|queued_spin_lock_slowpath(lock = 0xFFFFFF817F2A8A80, val = ?)
    -001|queued_spin_lock(inline) // try to hold nocb_gp_lock
    -001|do_raw_spin_lock(lock = 0xFFFFFF817F2A8A80)
    -002|__raw_spin_lock_irqsave(inline)
    -002|_raw_spin_lock_irqsave(lock = 0xFFFFFF817F2A8A80)
    -003|wake_nocb_gp_defer(inline)
    -003|__call_rcu_nocb_wake(rdp = 0xFFFFFF817F30B680)
    -004|__call_rcu_common(inline)
    -004|call_rcu(head = 0xFFFFFFC082EECC28, func = ?)
    -005|call_rcu_zapped(inline)
    -005|free_zapped_rcu(ch = ?)// hold graph lock
    -006|rcu_do_batch(rdp = 0xFFFFFF817F245680)
    -007|nocb_cb_wait(inline)
    -007|rcu_nocb_cb_kthread(arg = 0xFFFFFF817F245680)
    -008|kthread(_create = 0xFFFFFF80803122C0)
    -009|ret_from_fork(asm)
    
         rcuop/y
    -000|queued_spin_lock_slowpath(lock = 0xFFFFFFC08291BBC8, val = 0)
    -001|queued_spin_lock()
    -001|lockdep_lock()
    -001|graph_lock() // try to hold graph lock
    -002|lookup_chain_cache_add()
    -002|validate_chain()
    -003|lock_acquire
    -004|_raw_spin_lock_irqsave(lock = 0xFFFFFF817F211D80)
    -005|lock_timer_base(inline)
    -006|mod_timer(inline)
    -006|wake_nocb_gp_defer(inline)// hold nocb_gp_lock
    -006|__call_rcu_nocb_wake(rdp = 0xFFFFFF817F2A8680)
    -007|__call_rcu_common(inline)
    -007|call_rcu(head = 0xFFFFFFC0822E0B58, func = ?)
    -008|call_rcu_hurry(inline)
    -008|rcu_sync_call(inline)
    -008|rcu_sync_func(rhp = 0xFFFFFFC0822E0B58)
    -009|rcu_do_batch(rdp = 0xFFFFFF817F266680)
    -010|nocb_cb_wait(inline)
    -010|rcu_nocb_cb_kthread(arg = 0xFFFFFF817F266680)
    -011|kthread(_create = 0xFFFFFF8080363740)
    -012|ret_from_fork(asm)
    
    rcuop/x and rcuop/y are rcu nocb threads with the same nocb gp thread.
    This patch release the graph lock before lockdep call_rcu.
    
    Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use")
    Cc: [email protected]
    Cc: Boqun Feng <[email protected]>
    Cc: Waiman Long <[email protected]>
    Cc: Carlos Llamas <[email protected]>
    Cc: Bart Van Assche <[email protected]>
    Signed-off-by: Zhiguo Niu <[email protected]>
    Signed-off-by: Xuewen Yan <[email protected]>
    Reviewed-by: Waiman Long <[email protected]>
    Reviewed-by: Carlos Llamas <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Carlos Llamas <[email protected]>
    Acked-by: Paul E. McKenney <[email protected]>
    Signed-off-by: Boqun Feng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
m68k: Fix kernel_clone_args.flags in m68k_clone() [+ + +]
Author: Finn Thain <[email protected]>
Date:   Sun Aug 11 10:12:29 2024 +1000

    m68k: Fix kernel_clone_args.flags in m68k_clone()
    
    [ Upstream commit 09b3d870faa7bc3e96c0978ab3cf4e96e4b15571 ]
    
    Stan Johnson recently reported a failure from the 'dump' command:
    
      DUMP: Date of this level 0 dump: Fri Aug  9 23:37:15 2024
      DUMP: Dumping /dev/sda (an unlisted file system) to /dev/null
      DUMP: Label: none
      DUMP: Writing 10 Kilobyte records
      DUMP: mapping (Pass I) [regular files]
      DUMP: mapping (Pass II) [directories]
      DUMP: estimated 3595695 blocks.
      DUMP: Context save fork fails in parent 671
    
    The dump program uses the clone syscall with the CLONE_IO flag, that is,
    flags == 0x80000000. When that value is promoted from long int to u64 by
    m68k_clone(), it undergoes sign-extension. The new value includes
    CLONE_INTO_CGROUP so the validation in cgroup_css_set_fork() fails and
    the syscall returns -EBADF. Avoid sign-extension by casting to u32.
    
    Reported-by: Stan Johnson <[email protected]>
    Closes: https://lists.debian.org/debian-68k/2024/08/msg00000.html
    Fixes: 6aabc1facdb2 ("m68k: Implement copy_thread_tls()")
    Signed-off-by: Finn Thain <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/3463f1e5d4e95468dc9f3368f2b78ffa7b72199b.1723335149.git.fthain@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning [+ + +]
Author: Yunfei Dong <[email protected]>
Date:   Thu Jun 13 17:33:55 2024 +0800

    media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning
    
    [ Upstream commit 9be85491619f1953b8a29590ca630be571941ffa ]
    
    Fix a smatch static checker warning on vdec_h264_req_multi_if.c.
    Which leads to a kernel crash when fb is NULL.
    
    Fixes: 397edc703a10 ("media: mediatek: vcodec: add h264 decoder driver for mt8186")
    Signed-off-by: Yunfei Dong <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sebastian Fricke <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: mediatek: vcodec: Fix H264 stateless decoder smatch warning [+ + +]
Author: Yunfei Dong <[email protected]>
Date:   Thu Jun 13 17:33:57 2024 +0800

    media: mediatek: vcodec: Fix H264 stateless decoder smatch warning
    
    [ Upstream commit 7878d3a385efab560dce793b595447867fb163f2 ]
    
    Fix a smatch static checker warning on vdec_h264_req_if.c.
    Which leads to a kernel crash when fb is NULL.
    
    Fixes: 06fa5f757dc5 ("media: mtk-vcodec: vdec: support stateless H.264 decoding")
    Signed-off-by: Yunfei Dong <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sebastian Fricke <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning [+ + +]
Author: Yunfei Dong <[email protected]>
Date:   Thu Jun 13 17:33:56 2024 +0800

    media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning
    
    [ Upstream commit b113bc7c0e83b32f4dd2d291a2b6c4803e0a2c44 ]
    
    Fix a smatch static checker warning on vdec_vp8_req_if.c.
    Which leads to a kernel crash when fb is NULL.
    
    Fixes: 7a7ae26fd458 ("media: mediatek: vcodec: support stateless VP8 decoding")
    Signed-off-by: Yunfei Dong <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Signed-off-by: Sebastian Fricke <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE [+ + +]
Author: Biju Das <[email protected]>
Date:   Wed Jul 31 17:49:32 2024 +0100

    media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE
    
    [ Upstream commit 07668fb0f867388bfdac0b60dbf51a4ad789f8e7 ]
    
    The rzg2l-csi2 driver can be compiled as a module, but lacks
    MODULE_DEVICE_TABLE() and will therefore not be loaded automatically.
    Fix this.
    
    Fixes: 51e8415e39a9 ("media: platform: Add Renesas RZ/G2L MIPI CSI-2 receiver driver")
    Signed-off-by: Biju Das <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
minmax: avoid overly complex min()/max() macro arguments in xen [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Fri Jul 26 15:09:07 2024 -0700

    minmax: avoid overly complex min()/max() macro arguments in xen
    
    [ Upstream commit e8432ac802a028eaee6b1e86383d7cd8e9fb8431 ]
    
    We have some very fancy min/max macros that have tons of sanity checking
    to warn about mixed signedness etc.
    
    This is all things that a sane compiler should warn about, but there are
    no sane compiler interfaces for this, and '-Wsign-compare' is broken [1]
    and not useful.
    
    So then we compensate (some would say over-compensate) by doing the
    checks manually with some truly horrid macro games.
    
    And no, we can't just use __builtin_types_compatible_p(), because the
    whole question of "does it make sense to compare these two values" is a
    lot more complicated than that.
    
    For example, it makes a ton of sense to compare unsigned values with
    simple constants like "5", even if that is indeed a signed type.  So we
    have these very strange macros to try to make sensible type checking
    decisions on the arguments to 'min()' and 'max()'.
    
    But that can cause enormous code expansion if the min()/max() macros are
    used with complicated expressions, and particularly if you nest these
    things so that you get the first big expansion then expanded again.
    
    The xen setup.c file ended up ballooning to over 50MB of preprocessed
    noise that takes 15s to compile (obviously depending on the build host),
    largely due to one single line.
    
    So let's split that one single line to just be simpler.  I think it ends
    up being more legible to humans too at the same time.  Now that single
    file compiles in under a second.
    
    Reported-and-reviewed-by: Lorenzo Stoakes <[email protected]>
    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://staticthinking.wordpress.com/2023/07/25/wsign-compare-is-garbage/ [1]
    Cc: David Laight <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Stable-dep-of: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory")
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu read lock [+ + +]
Author: Liam R. Howlett <[email protected]>
Date:   Wed Sep 4 17:12:04 2024 -0700

    mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu read lock
    
    commit fb497d6db7c19c797cbd694b52d1af87c4eebcc6 upstream.
    
    Traversing VMAs of a given maple tree should be protected by rcu read
    lock.  However, __damon_va_three_regions() is not doing the protection.
    Hold the lock.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: d0cf3dd47f0d ("damon: convert __damon_va_three_regions to use the VMA iterator")
    Signed-off-by: Liam R. Howlett <[email protected]>
    Signed-off-by: SeongJae Park <[email protected]>
    Reported-by: Guenter Roeck <[email protected]>
    Closes: https://lore.kernel.org/[email protected]
    Tested-by: Guenter Roeck <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/filemap: optimize filemap folio adding [+ + +]
Author: Kairui Song <[email protected]>
Date:   Wed Oct 2 05:06:25 2024 +0800

    mm/filemap: optimize filemap folio adding
    
    commit 6758c1128ceb45d1a35298912b974eb4895b7dd9 upstream.
    
    Instead of doing multiple tree walks, do one optimism range check with
    lock hold, and exit if raced with another insertion.  If a shadow exists,
    check it with a new xas_get_order helper before releasing the lock to
    avoid redundant tree walks for getting its order.
    
    Drop the lock and do the allocation only if a split is needed.
    
    In the best case, it only need to walk the tree once.  If it needs to
    alloc and split, 3 walks are issued (One for first ranged conflict check
    and order retrieving, one for the second check after allocation, one for
    the insert after split).
    
    Testing with 4K pages, in an 8G cgroup, with 16G brd as block device:
    
      echo 3 > /proc/sys/vm/drop_caches
    
      fio -name=cached --numjobs=16 --filename=/mnt/test.img \
        --buffered=1 --ioengine=mmap --rw=randread --time_based \
        --ramp_time=30s --runtime=5m --group_reporting
    
    Before:
    bw (  MiB/s): min= 1027, max= 3520, per=100.00%, avg=2445.02, stdev=18.90, samples=8691
    iops        : min=263001, max=901288, avg=625924.36, stdev=4837.28, samples=8691
    
    After (+7.3%):
    bw (  MiB/s): min=  493, max= 3947, per=100.00%, avg=2625.56, stdev=25.74, samples=8651
    iops        : min=126454, max=1010681, avg=672142.61, stdev=6590.48, samples=8651
    
    Test result with THP (do a THP randread then switch to 4K page in hope it
    issues a lot of splitting):
    
      echo 3 > /proc/sys/vm/drop_caches
    
      fio -name=cached --numjobs=16 --filename=/mnt/test.img \
          --buffered=1 --ioengine=mmap -thp=1 --readonly \
          --rw=randread --time_based --ramp_time=30s --runtime=10m \
          --group_reporting
    
      fio -name=cached --numjobs=16 --filename=/mnt/test.img \
          --buffered=1 --ioengine=mmap \
          --rw=randread --time_based --runtime=5s --group_reporting
    
    Before:
    bw (  KiB/s): min= 4141, max=14202, per=100.00%, avg=7935.51, stdev=96.85, samples=18976
    iops        : min= 1029, max= 3548, avg=1979.52, stdev=24.23, samples=18976·
    
    READ: bw=4545B/s (4545B/s), 4545B/s-4545B/s (4545B/s-4545B/s), io=64.0KiB (65.5kB), run=14419-14419msec
    
    After (+12.5%):
    bw (  KiB/s): min= 4611, max=15370, per=100.00%, avg=8928.74, stdev=105.17, samples=19146
    iops        : min= 1151, max= 3842, avg=2231.27, stdev=26.29, samples=19146
    
    READ: bw=4635B/s (4635B/s), 4635B/s-4635B/s (4635B/s-4635B/s), io=64.0KiB (65.5kB), run=14137-14137msec
    
    The performance is better for both 4K (+7.5%) and THP (+12.5%) cached read.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Kairui Song <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Closes: https://lore.kernel.org/linux-mm/[email protected]/
    [ [email protected]: minor adjustment of variable declarations ]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm/filemap: return early if failed to allocate memory for split [+ + +]
Author: Kairui Song <[email protected]>
Date:   Wed Oct 2 05:06:23 2024 +0800

    mm/filemap: return early if failed to allocate memory for split
    
    commit de60fd8ddeda2b41fbe11df11733838c5f684616 upstream.
    
    xas_split_alloc could fail with NOMEM, and in such case, it should abort
    early instead of keep going and fail the xas_split below.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Kairui Song <[email protected]>
    Acked-by: Matthew Wilcox (Oracle) <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 6758c1128ceb ("mm/filemap: optimize filemap folio adding")
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: call the security_mmap_file() LSM hook in remap_file_pages() [+ + +]
Author: Shu Han <[email protected]>
Date:   Tue Sep 17 17:41:04 2024 +0800

    mm: call the security_mmap_file() LSM hook in remap_file_pages()
    
    commit ea7e2d5e49c05e5db1922387b09ca74aa40f46e2 upstream.
    
    The remap_file_pages syscall handler calls do_mmap() directly, which
    doesn't contain the LSM security check. And if the process has called
    personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
    RW pages, this will actually result in remapping the pages to RWX,
    bypassing a W^X policy enforced by SELinux.
    
    So we should check prot by security_mmap_file LSM hook in the
    remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
    potentially permits an attacker to bypass a W^X policy enforced by
    SELinux.
    
    The bypass is similar to CVE-2016-10044, which bypass the same thing via
    AIO and can be found in [1].
    
    The PoC:
    
    $ cat > test.c
    
    int main(void) {
            size_t pagesz = sysconf(_SC_PAGE_SIZE);
            int mfd = syscall(SYS_memfd_create, "test", 0);
            const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
                    MAP_SHARED, mfd, 0);
            unsigned int old = syscall(SYS_personality, 0xffffffff);
            syscall(SYS_personality, READ_IMPLIES_EXEC | old);
            syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
            syscall(SYS_personality, old);
            // show the RWX page exists even if W^X policy is enforced
            int fd = open("/proc/self/maps", O_RDONLY);
            unsigned char buf2[1024];
            while (1) {
                    int ret = read(fd, buf2, 1024);
                    if (ret <= 0) break;
                    write(1, buf2, ret);
            }
            close(fd);
    }
    
    $ gcc test.c -o test
    $ ./test | grep rwx
    7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)
    
    Link: https://project-zero.issues.chromium.org/issues/42452389 [1]
    Cc: [email protected]
    Signed-off-by: Shu Han <[email protected]>
    Acked-by: Stephen Smalley <[email protected]>
    [PM: subject line tweaks]
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mm: only enforce minimum stack gap size if it's sensible [+ + +]
Author: David Gow <[email protected]>
Date:   Sat Aug 3 15:46:41 2024 +0800

    mm: only enforce minimum stack gap size if it's sensible
    
    commit 69b50d4351ed924f29e3d46b159e28f70dfc707f upstream.
    
    The generic mmap_base code tries to leave a gap between the top of the
    stack and the mmap base address, but enforces a minimum gap size (MIN_GAP)
    of 128MB, which is too large on some setups.  In particular, on arm tasks
    without ADDR_LIMIT_32BIT, the STACK_TOP value is less than 128MB, so it's
    impossible to fit such a gap in.
    
    Only enforce this minimum if MIN_GAP < MAX_GAP, as we'd prefer to honour
    MAX_GAP, which is defined proportionally, so scales better and always
    leaves us with both _some_ stack space and some room for mmap.
    
    This fixes the usercopy KUnit test suite on 32-bit arm, as it doesn't set
    any personality flags so gets the default (in this case 26-bit) task size.
    This test can be run with: ./tools/testing/kunit/kunit.py run --arch arm
    usercopy --make_options LLVM=1
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: dba79c3df4a2 ("arm: use generic mmap top-down layout and brk randomization")
    Signed-off-by: David Gow <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Cc: Alexandre Ghiti <[email protected]>
    Cc: Linus Walleij <[email protected]>
    Cc: Luis Chamberlain <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Russell King <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
module: Fix KCOV-ignored file name [+ + +]
Author: Dmitry Vyukov <[email protected]>
Date:   Tue Jun 11 09:50:32 2024 +0200

    module: Fix KCOV-ignored file name
    
    commit f34d086fb7102fec895fd58b9e816b981b284c17 upstream.
    
    module.c was renamed to main.c, but the Makefile directive was copy-pasted
    verbatim with the old file name.  Fix up the file name.
    
    Fixes: cfc1d277891e ("module: Move all into module/")
    Signed-off-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Alexander Potapenko <[email protected]>
    Reviewed-by: Marco Elver <[email protected]>
    Reviewed-by: Andrey Konovalov <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/bc0cf790b4839c5e38e2fafc64271f620568a39e.1718092070.git.dvyukov@google.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mount: handle OOM on mnt_warn_timestamp_expiry [+ + +]
Author: Olaf Hering <[email protected]>
Date:   Tue Jul 30 10:58:13 2024 +0200

    mount: handle OOM on mnt_warn_timestamp_expiry
    
    [ Upstream commit 4bcda1eaf184e308f07f9c61d3a535f9ce477ce8 ]
    
    If no page could be allocated, an error pointer was used as format
    string in pr_warn.
    
    Rearrange the code to return early in case of OOM. Also add a check
    for the return value of d_path.
    
    Fixes: f8b92ba67c5d ("mount: Add mount warning for impending timestamp expiry")
    Signed-off-by: Olaf Hering <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [brauner: rewrite commit and commit message]
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtd: powernv: Add check devm_kasprintf() returned value [+ + +]
Author: Charles Han <[email protected]>
Date:   Wed Aug 28 17:24:27 2024 +0800

    mtd: powernv: Add check devm_kasprintf() returned value
    
    [ Upstream commit 395999829880a106bb95f0ce34e6e4c2b43c6a5d ]
    
    devm_kasprintf() can return a NULL pointer on failure but this
    returned value is not checked.
    
    Fixes: acfe63ec1c59 ("mtd: Convert to using %pOFn instead of device_node.name")
    Signed-off-by: Charles Han <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Mon Aug 26 17:30:18 2024 +0200

    mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips
    
    [ Upstream commit 81cb3be3261e766a1f8efab9e3154a4f4fd9d03d ]
    
    There are some un-freed resources in one of the error path which would
    benefit from a helper going through all the registered mtk chips one by
    one and perform all the necessary cleanup. This is precisely what the
    remove path does, so let's extract the logic in a helper.
    
    There is no functional change.
    
    Signed-off-by: Miquel Raynal <[email protected]>
    Reviewed-by: Pratyush Yadav <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Stable-dep-of: 2073ae37d550 ("mtd: rawnand: mtk: Fix init error path")
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: mtk: Fix init error path [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Mon Aug 26 17:30:19 2024 +0200

    mtd: rawnand: mtk: Fix init error path
    
    [ Upstream commit 2073ae37d550ea32e8545edaa94ef10b4fef7235 ]
    
    Reviewing a series converting the for_each_chil_of_node() loops into
    their _scoped variants made me realize there was no cleanup of the
    already registered NAND devices upon error which may leak memory on
    systems with more than a chip when this error occurs. We should call the
    _nand_chips_cleanup() function when this happens.
    
    Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device")
    Signed-off-by: Miquel Raynal <[email protected]>
    Reviewed-by: Pratyush Yadav <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

mtd: rawnand: mtk: Use for_each_child_of_node_scoped() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Aug 26 17:43:25 2024 +0800

    mtd: rawnand: mtk: Use for_each_child_of_node_scoped()
    
    [ Upstream commit 8795952679494b111b7b2ba08bb54ac408daca3b ]
    
    Avoids the need for manual cleanup of_node_put() in early exits
    from the loop.
    
    Signed-off-by: Jinjie Ruan <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Stable-dep-of: 2073ae37d550 ("mtd: rawnand: mtk: Fix init error path")
    Signed-off-by: Sasha Levin <[email protected]>

mtd: slram: insert break after errors in parsing the map [+ + +]
Author: Mirsad Todorovac <[email protected]>
Date:   Fri Jul 12 01:43:20 2024 +0200

    mtd: slram: insert break after errors in parsing the map
    
    [ Upstream commit 336c218dd7f0588ed8a7345f367975a00a4f003f ]
    
    GCC 12.3.0 compiler on linux-next next-20240709 tree found the execution
    path in which, due to lazy evaluation, devlength isn't initialised with the
    parsed string:
    
       289          while (map) {
       290                  devname = devstart = devlength = NULL;
       291
       292                  if (!(devname = strsep(&map, ","))) {
       293                          E("slram: No devicename specified.\n");
       294                          break;
       295                  }
       296                  T("slram: devname = %s\n", devname);
       297                  if ((!map) || (!(devstart = strsep(&map, ",")))) {
       298                          E("slram: No devicestart specified.\n");
       299                  }
       300                  T("slram: devstart = %s\n", devstart);
     → 301                  if ((!map) || (!(devlength = strsep(&map, ",")))) {
       302                          E("slram: No devicelength / -end specified.\n");
       303                  }
     → 304                  T("slram: devlength = %s\n", devlength);
       305                  if (parse_cmdline(devname, devstart, devlength) != 0) {
       306                          return(-EINVAL);
       307                  }
    
    Parsing should be finished after map == NULL, so a break is best inserted after
    each E("slram: ... \n") error message.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: Miquel Raynal <[email protected]>
    Cc: Richard Weinberger <[email protected]>
    Cc: Vignesh Raghavendra <[email protected]>
    Cc: [email protected]
    Signed-off-by: Mirsad Todorovac <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Link: https://lore.kernel.org/linux-mtd/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
nbd: fix race between timeout and normal completion [+ + +]
Author: Ming Lei <[email protected]>
Date:   Fri Aug 30 11:41:45 2024 +0800

    nbd: fix race between timeout and normal completion
    
    [ Upstream commit c9ea57c91f03bcad415e1a20113bdb2077bcf990 ]
    
    If request timetout is handled by nbd_requeue_cmd(), normal completion
    has to be stopped for avoiding to complete this requeued request, other
    use-after-free can be triggered.
    
    Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime
    make sure that cmd->lock is grabbed for clearing the flag and the
    requeue.
    
    Cc: Josef Bacik <[email protected]>
    Cc: Yu Kuai <[email protected]>
    Fixes: 2895f1831e91 ("nbd: don't clear 'NBD_CMD_INFLIGHT' flag if request is not completed")
    Signed-off-by: Ming Lei <[email protected]>
    Reviewed-by: Yu Kuai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: enetc: Use IRQF_NO_AUTOEN flag in request_irq() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Wed Sep 11 17:44:44 2024 +0800

    net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()
    
    [ Upstream commit 799a9225997799f7b1b579bc50a93b78b4fb2a01 ]
    
    disable_irq() after request_irq() still has a time gap in which
    interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
    disable IRQ auto-enable when request IRQ.
    
    Fixes: bbb96dc7fa1a ("enetc: Factor out the traffic start/stop procedures")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input [+ + +]
Author: Justin Iurman <[email protected]>
Date:   Wed Sep 11 19:45:57 2024 +0200

    net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input
    
    [ Upstream commit 2c84b0aa28b9e73e8c4b4ce038269469434ae372 ]
    
    Free the skb before returning from rpl_input when skb_cow_head() fails.
    Use a "drop" label and goto instructions.
    
    Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel")
    Signed-off-by: Justin Iurman <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Mon Sep 16 20:57:13 2024 +0200

    net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL
    
    [ Upstream commit 93c21077bb9ba08807c459982d440dbbee4c7af3 ]
    
    The rpl sr tunnel code contains calls to dst_cache_*() which are
    only present when the dst cache is built.
    Select DST_CACHE to build the dst cache, similar to other kconfig
    options in the same file.
    Compiling the rpl sr tunnel without DST_CACHE will lead to linker
    errors.
    
    Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel")
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Simon Horman <[email protected]> # build-tested
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: qrtr: Update packets cloning when broadcasting [+ + +]
Author: Youssef Samir <[email protected]>
Date:   Mon Sep 16 19:08:58 2024 +0200

    net: qrtr: Update packets cloning when broadcasting
    
    [ Upstream commit f011b313e8ebd5b7abd8521b5119aecef403de45 ]
    
    When broadcasting data to multiple nodes via MHI, using skb_clone()
    causes all nodes to receive the same header data. This can result in
    packets being discarded by endpoints, leading to lost data.
    
    This issue occurs when a socket is closed, and a QRTR_TYPE_DEL_CLIENT
    packet is broadcasted. All nodes receive the same destination node ID,
    causing the node connected to the client to discard the packet and
    remain unaware of the client's deletion.
    
    Replace skb_clone() with pskb_copy(), to create a separate copy of
    the header for each sk_buff.
    
    Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
    Signed-off-by: Youssef Samir <[email protected]>
    Reviewed-by: Jeffery Hugo <[email protected]>
    Reviewed-by: Carl Vanderlip <[email protected]>
    Reviewed-by: Chris Lew <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition [+ + +]
Author: Kaixin Wang <[email protected]>
Date:   Sun Sep 15 22:40:46 2024 +0800

    net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition
    
    [ Upstream commit b5109b60ee4fcb2f2bb24f589575e10cc5283ad4 ]
    
    In the ether3_probe function, a timer is initialized with a callback
    function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is
    started, there is a risk of a race condition if the module or device
    is removed, triggering the ether3_remove function to perform cleanup.
    The sequence of operations that may lead to a UAF bug is as follows:
    
    CPU0                                    CPU1
    
                          |  ether3_ledoff
    ether3_remove         |
      free_netdev(dev);   |
      put_devic           |
      kfree(dev);         |
     |  ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2);
                          | // use dev
    
    Fix it by ensuring that the timer is canceled before proceeding with
    the cleanup in ether3_remove.
    
    Fixes: 6fd9c53f7186 ("net: seeq: Convert timers to use timer_setup()")
    Signed-off-by: Kaixin Wang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: dwmac-loongson: Init ref and PTP clocks rate [+ + +]
Author: Yanteng Si <[email protected]>
Date:   Wed Aug 7 21:48:02 2024 +0800

    net: stmmac: dwmac-loongson: Init ref and PTP clocks rate
    
    [ Upstream commit c70f3163681381c15686bdd2fe56bf4af9b8aaaa ]
    
    Reference and PTP clocks rate of the Loongson GMAC devices is 125MHz.
    (So is in the GNET devices which support is about to be added.) Set
    the respective plat_stmmacenet_data field up in accordance with that
    so to have the coalesce command and timestamping work correctly.
    
    Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson")
    Signed-off-by: Feiyang Chen <[email protected]>
    Signed-off-by: Yinggang Gu <[email protected]>
    Reviewed-by: Serge Semin <[email protected]>
    Acked-by: Huacai Chen <[email protected]>
    Signed-off-by: Yanteng Si <[email protected]>
    Tested-by: Serge Semin <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: stmmac: set PP_FLAG_DMA_SYNC_DEV only if XDP is enabled [+ + +]
Author: Furong Xu <[email protected]>
Date:   Thu Sep 19 20:10:28 2024 +0800

    net: stmmac: set PP_FLAG_DMA_SYNC_DEV only if XDP is enabled
    
    [ Upstream commit b514c47ebf41a6536551ed28a05758036e6eca7c ]
    
    Commit 5fabb01207a2 ("net: stmmac: Add initial XDP support") sets
    PP_FLAG_DMA_SYNC_DEV flag for page_pool unconditionally,
    page_pool_recycle_direct() will call page_pool_dma_sync_for_device()
    on every page even the page is not going to be reused by XDP program.
    
    When XDP is not enabled, the page which holds the received buffer
    will be recycled once the buffer is copied into new SKB by
    skb_copy_to_linear_data(), then the MAC core will never reuse this
    page any longer. Always setting PP_FLAG_DMA_SYNC_DEV wastes CPU cycles
    on unnecessary calling of page_pool_dma_sync_for_device().
    
    After this patch, up to 9% noticeable performance improvement was observed
    on certain platforms.
    
    Fixes: 5fabb01207a2 ("net: stmmac: Add initial XDP support")
    Signed-off-by: Furong Xu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tipc: avoid possible garbage value [+ + +]
Author: Su Hui <[email protected]>
Date:   Thu Sep 12 19:01:20 2024 +0800

    net: tipc: avoid possible garbage value
    
    [ Upstream commit 99655a304e450baaae6b396cb942b9e47659d644 ]
    
    Clang static checker (scan-build) warning:
    net/tipc/bcast.c:305:4:
    The expression is an uninitialized value. The computed value will also
    be garbage [core.uninitialized.Assign]
      305 |                         (*cong_link_cnt)++;
          |                         ^~~~~~~~~~~~~~~~~~
    
    tipc_rcast_xmit() will increase cong_link_cnt's value, but cong_link_cnt
    is uninitialized. Although it won't really cause a problem, it's better
    to fix it.
    
    Fixes: dca4a17d24ee ("tipc: fix potential hanging after b/rcast changing")
    Signed-off-by: Su Hui <[email protected]>
    Reviewed-by: Justin Stitt <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: xilinx: axienet: Fix packet counting [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri Sep 13 10:51:56 2024 -0400

    net: xilinx: axienet: Fix packet counting
    
    [ Upstream commit 5a6caa2cfabb559309b5ce29ee7c8e9ce1a9a9df ]
    
    axienet_free_tx_chain returns the number of DMA descriptors it's
    handled. However, axienet_tx_poll treats the return as the number of
    packets. When scatter-gather SKBs are enabled, a single packet may use
    multiple DMA descriptors, which causes incorrect packet counts. Fix this
    by explicitly keepting track of the number of packets processed as
    separate from the DMA descriptors.
    
    Budget does not affect the number of Tx completions we can process for
    NAPI, so we use the ring size as the limit instead of budget. As we no
    longer return the number of descriptors processed to axienet_tx_poll, we
    now update tx_bd_ci in axienet_free_tx_chain.
    
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Signed-off-by: Sean Anderson <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: xilinx: axienet: Schedule NAPI in two steps [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri Sep 13 10:57:11 2024 -0400

    net: xilinx: axienet: Schedule NAPI in two steps
    
    [ Upstream commit ba0da2dc934ec5ac32bbeecbd0670da16ba03565 ]
    
    As advised by Documentation/networking/napi.rst, masking IRQs after
    calling napi_schedule can be racy. Avoid this by only masking/scheduling
    if napi_schedule_prep returns true.
    
    Fixes: 9e2bc267e780 ("net: axienet: Use NAPI for TX completion path")
    Fixes: cc37610caaf8 ("net: axienet: implement NAPI and GRO receive")
    Signed-off-by: Sean Anderson <[email protected]>
    Reviewed-by: Shannon Nelson <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
netfilter: ctnetlink: compile ctnetlink_label_size with CONFIG_NF_CONNTRACK_EVENTS [+ + +]
Author: Simon Horman <[email protected]>
Date:   Mon Sep 16 16:14:41 2024 +0100

    netfilter: ctnetlink: compile ctnetlink_label_size with CONFIG_NF_CONNTRACK_EVENTS
    
    [ Upstream commit e1f1ee0e9ad8cbe660f5c104e791c5f1a7cf4c31 ]
    
    Only provide ctnetlink_label_size when it is used,
    which is when CONFIG_NF_CONNTRACK_EVENTS is configured.
    
    Flagged by clang-18 W=1 builds as:
    
    .../nf_conntrack_netlink.c:385:19: warning: unused function 'ctnetlink_label_size' [-Wunused-function]
      385 | static inline int ctnetlink_label_size(const struct nf_conn *ct)
          |                   ^~~~~~~~~~~~~~~~~~~~
    
    The condition on CONFIG_NF_CONNTRACK_LABELS being removed by
    this patch guards compilation of non-trivial implementations
    of ctnetlink_dump_labels() and ctnetlink_label_size().
    
    However, this is not necessary as each of these functions
    will always return 0 if CONFIG_NF_CONNTRACK_LABELS is not defined
    as each function starts with the equivalent of:
    
            struct nf_conn_labels *labels = nf_ct_labels_find(ct);
    
            if (!labels)
                    return 0;
    
    And nf_ct_labels_find always returns NULL if CONFIG_NF_CONNTRACK_LABELS
    is not enabled.  So I believe that the compiler optimises the code away
    in such cases anyway.
    
    Found by inspection.
    Compile tested only.
    
    Originally splitted in two patches, Pablo Neira Ayuso collapsed them and
    added Fixes: tag.
    
    Fixes: 0ceabd83875b ("netfilter: ctnetlink: deliver labels to userspace")
    Link: https://lore.kernel.org/netfilter-devel/[email protected]/
    Signed-off-by: Simon Horman <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 13 17:06:15 2024 +0000

    netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()
    
    [ Upstream commit 9c778fe48d20ef362047e3376dee56d77f8500d4 ]
    
    syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
    garbage on the four reserved tcp bits (th->res1)
    
    Use skb_put_zero() to clear the whole TCP header,
    as done in nf_reject_ip_tcphdr_put()
    
    BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
      nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
      do_softirq+0x9a/0x100 kernel/softirq.c:455
      __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
      local_bh_enable include/linux/bottom_half.h:33 [inline]
      rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
      __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
      dev_queue_xmit include/linux/netdevice.h:3105 [inline]
      neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
      neigh_output include/net/neighbour.h:542 [inline]
      ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
      __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
      ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
      NF_HOOK_COND include/linux/netfilter.h:303 [inline]
      ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
      dst_output include/net/dst.h:450 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
      inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
      __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
      tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
      tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
      tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
      __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
      inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
      __sys_connect_file net/socket.c:2061 [inline]
      __sys_connect+0x606/0x690 net/socket.c:2078
      __do_sys_connect net/socket.c:2088 [inline]
      __se_sys_connect net/socket.c:2085 [inline]
      __x64_sys_connect+0x91/0xe0 net/socket.c:2085
      x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was stored to memory at:
      nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Uninit was stored to memory at:
      nf_reject_ip6_tcphdr_put+0x2ca/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:231
      nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:3998 [inline]
      slab_alloc_node mm/slub.c:4041 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4084
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
      alloc_skb include/linux/skbuff.h:1320 [inline]
      nf_send_reset6+0x98d/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:327
      nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
      expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
      nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
      nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      NF_HOOK include/linux/netfilter.h:312 [inline]
      ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
      process_backlog+0x4ad/0xa50 net/core/dev.c:6108
      __napi_poll+0xe7/0x980 net/core/dev.c:6772
      napi_poll net/core/dev.c:6841 [inline]
      net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
      handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
      __do_softirq+0x14/0x1a kernel/softirq.c:588
    
    Fixes: c8d7b98bec43 ("netfilter: move nf_send_resetX() code to nf_reject_ipvX modules")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Pablo Neira Ayuso <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:41 2024 +0200

    netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire
    
    [ Upstream commit e0c47281723f301894c14e6f5cd5884fdfb813f9 ]
    
    Element timeout that is below CONFIG_HZ never expires because the
    timeout extension is not allocated given that nf_msecs_to_jiffies64()
    returns 0. Set timeout to the minimum value to honor timeout.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: Keep deleted flowtable hooks until after RCU [+ + +]
Author: Phil Sutter <[email protected]>
Date:   Thu Sep 12 14:21:33 2024 +0200

    netfilter: nf_tables: Keep deleted flowtable hooks until after RCU
    
    [ Upstream commit 642c89c475419b4d0c0d90e29d9c1a0e4351f379 ]
    
    Documentation of list_del_rcu() warns callers to not immediately free
    the deleted list item. While it seems not necessary to use the
    RCU-variant of list_del() here in the first place, doing so seems to
    require calling kfree_rcu() on the deleted item as well.
    
    Fixes: 3f0465a9ef02 ("netfilter: nf_tables: dynamically allocate hooks per net_device in flowtables")
    Signed-off-by: Phil Sutter <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject element expiration with no timeout [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:49 2024 +0200

    netfilter: nf_tables: reject element expiration with no timeout
    
    [ Upstream commit d2dc429ecb4e79ad164028d965c00f689e6f6d06 ]
    
    If element timeout is unset and set provides no default timeout, the
    element expiration is silently ignored, reject this instead to let user
    know this is unsupported.
    
    Also prepare for supporting timeout that never expire, where zero
    timeout and expiration must be also rejected.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: reject expiration higher than timeout [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:06:58 2024 +0200

    netfilter: nf_tables: reject expiration higher than timeout
    
    [ Upstream commit c0f38a8c60174368aed1d0f9965d733195f15033 ]
    
    Report ERANGE to userspace if user specifies an expiration larger than
    the timeout.
    
    Fixes: 8e1102d5a159 ("netfilter: nf_tables: support timeouts larger than 23 days")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: remove annotation to access set timeout while holding lock [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 3 01:07:06 2024 +0200

    netfilter: nf_tables: remove annotation to access set timeout while holding lock
    
    [ Upstream commit 15d8605c0cf4fc9cf4386cae658c68a0fd4bdb92 ]
    
    Mutex is held when adding an element, no need for READ_ONCE, remove it.
    
    Fixes: 123b99619cca ("netfilter: nf_tables: honor set timeout and garbage collection updates")
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

netfilter: nf_tables: use rcu chain hook list iterator from netlink dump path [+ + +]
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue Sep 17 23:07:46 2024 +0200

    netfilter: nf_tables: use rcu chain hook list iterator from netlink dump path
    
    [ Upstream commit 4ffcf5ca81c3b83180473eb0d3c010a1a7c6c4de ]
    
    Lockless iteration over hook list is possible from netlink dump path,
    use rcu variant to iterate over the hook list as is done with flowtable
    hooks.
    
    Fixes: b9703ed44ffb ("netfilter: nf_tables: support for adding new devices to an existing netdev chain")
    Reported-by: Phil Sutter <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: fix memory leak in error path of nfs4_do_reclaim [+ + +]
Author: Li Lingfeng <[email protected]>
Date:   Wed Sep 4 20:34:57 2024 +0800

    nfs: fix memory leak in error path of nfs4_do_reclaim
    
    commit 8f6a7c9467eaf39da4c14e5474e46190ab3fb529 upstream.
    
    Commit c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in
    nfs4_do_reclaim()") separate out the freeing of the state owners from
    nfs4_purge_state_owners() and finish it outside the rcu lock.
    However, the error path is omitted. As a result, the state owners in
    "freeme" will not be released.
    Fix it by adding freeing in the error path.
    
    Fixes: c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()")
    Signed-off-by: Li Lingfeng <[email protected]>
    Cc: [email protected] # v5.3+
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nfsd: call cache_put if xdr_reserve_space returns NULL [+ + +]
Author: Guoqing Jiang <[email protected]>
Date:   Wed Aug 21 22:03:18 2024 +0800

    nfsd: call cache_put if xdr_reserve_space returns NULL
    
    [ Upstream commit d078cbf5c38de83bc31f83c47dcd2184c04a50c7 ]
    
    If not enough buffer space available, but idmap_lookup has triggered
    lookup_fn which calls cache_get and returns successfully. Then we
    missed to call cache_put here which pairs with cache_get.
    
    Fixes: ddd1ea563672 ("nfsd4: use xdr_reserve_space in attribute encoding")
    Signed-off-by: Guoqing Jiang <[email protected]>
    Reviwed-by: Jeff Layton <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: fix refcount leak when file is unhashed after being found [+ + +]
Author: Jeff Layton <[email protected]>
Date:   Wed Jul 10 09:05:32 2024 -0400

    nfsd: fix refcount leak when file is unhashed after being found
    
    [ Upstream commit 8a7926176378460e0d91e02b03f0ff20a8709a60 ]
    
    If we wait_for_construction and find that the file is no longer hashed,
    and we're going to retry the open, the old nfsd_file reference is
    currently leaked. Put the reference before retrying.
    
    Fixes: c6593366c0bf ("nfsd: don't kill nfsd_files because of lease break error")
    Signed-off-by: Jeff Layton <[email protected]>
    Tested-by: Youzhong Yang <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire [+ + +]
Author: Jeff Layton <[email protected]>
Date:   Thu Jul 11 15:11:13 2024 -0400

    nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire
    
    [ Upstream commit 81a95c2b1d605743220f28db04b8da13a65c4059 ]
    
    Given that we do the search and insertion while holding the i_lock, I
    don't think it's possible for us to get EEXIST here. Remove this case.
    
    Fixes: c6593366c0bf ("nfsd: don't kill nfsd_files because of lease break error")
    Signed-off-by: Jeff Layton <[email protected]>
    Tested-by: Youzhong Yang <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfsd: return -EINVAL when namelen is 0 [+ + +]
Author: Li Lingfeng <[email protected]>
Date:   Tue Sep 3 19:14:46 2024 +0800

    nfsd: return -EINVAL when namelen is 0
    
    [ Upstream commit 22451a16b7ab7debefce660672566be887db1637 ]
    
    When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
    result in namelen being 0, which will cause memdup_user() to return
    ZERO_SIZE_PTR.
    When we access the name.data that has been assigned the value of
    ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
    triggered.
    
    [ T1205] ==================================================================
    [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
    [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
    [ T1205]
    [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
    [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
    [ T1205] Call Trace:
    [ T1205]  dump_stack+0x9a/0xd0
    [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  __kasan_report.cold+0x34/0x84
    [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  kasan_report+0x3a/0x50
    [ T1205]  nfs4_client_to_reclaim+0xe9/0x260
    [ T1205]  ? nfsd4_release_lockowner+0x410/0x410
    [ T1205]  cld_pipe_downcall+0x5ca/0x760
    [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
    [ T1205]  ? down_write_killable_nested+0x170/0x170
    [ T1205]  ? avc_policy_seqno+0x28/0x40
    [ T1205]  ? selinux_file_permission+0x1b4/0x1e0
    [ T1205]  rpc_pipe_write+0x84/0xb0
    [ T1205]  vfs_write+0x143/0x520
    [ T1205]  ksys_write+0xc9/0x170
    [ T1205]  ? __ia32_sys_read+0x50/0x50
    [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110
    [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110
    [ T1205]  do_syscall_64+0x33/0x40
    [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1
    [ T1205] RIP: 0033:0x7fdbdb761bc7
    [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
    [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
    [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
    [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
    [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
    [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
    [ T1205] ==================================================================
    
    Fix it by checking namelen.
    
    Signed-off-by: Li Lingfeng <[email protected]>
    Fixes: 74725959c33c ("nfsd: un-deprecate nfsdcld")
    Reviewed-by: Jeff Layton <[email protected]>
    Reviewed-by: Scott Mayhew <[email protected]>
    Tested-by: Scott Mayhew <[email protected]>
    Signed-off-by: Chuck Lever <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nilfs2: determine empty node blocks as corrupted [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:08 2024 +0900

    nilfs2: determine empty node blocks as corrupted
    
    [ Upstream commit 111b812d3662f3a1b831d19208f83aa711583fe6 ]
    
    Due to the nature of b-trees, nilfs2 itself and admin tools such as
    mkfs.nilfs2 will never create an intermediate b-tree node block with 0
    child nodes, nor will they delete (key, pointer)-entries that would result
    in such a state.  However, it is possible that a b-tree node block is
    corrupted on the backing device and is read with 0 child nodes.
    
    Because operation is not guaranteed if the number of child nodes is 0 for
    intermediate node blocks other than the root node, modify
    nilfs_btree_node_broken(), which performs sanity checks when reading a
    b-tree node block, so that such cases will be judged as metadata
    corruption.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:07 2024 +0900

    nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
    
    [ Upstream commit 9403001ad65ae4f4c5de368bdda3a0636b51d51a ]
    
    Patch series "nilfs2: fix potential issues with empty b-tree nodes".
    
    This series addresses three potential issues with empty b-tree nodes that
    can occur with corrupted filesystem images, including one recently
    discovered by syzbot.
    
    This patch (of 3):
    
    If a b-tree is broken on the device, and the b-tree height is greater than
    2 (the level of the root node is greater than 1) even if the number of
    child nodes of the b-tree root is 0, a NULL pointer dereference occurs in
    nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().
    
    This is because, when the number of child nodes of the b-tree root is 0,
    nilfs_btree_do_lookup() does not set the block buffer head in any of
    path[x].bp_bh, leaving it as the initial value of NULL, but if the level
    of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),
    which accesses the buffer memory of path[x].bp_bh, is called.
    
    Fix this issue by adding a check to nilfs_btree_root_broken(), which
    performs sanity checks when reading the root node from the device, to
    detect this inconsistency.
    
    Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause
    early on.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=9bff4c7b992038a7409f
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nilfs2: fix potential oob read in nilfs_btree_check_delete() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Wed Sep 4 17:13:09 2024 +0900

    nilfs2: fix potential oob read in nilfs_btree_check_delete()
    
    [ Upstream commit f9c96351aa6718b42a9f42eaf7adce0356bdb5e8 ]
    
    The function nilfs_btree_check_delete(), which checks whether degeneration
    to direct mapping occurs before deleting a b-tree entry, causes memory
    access outside the block buffer when retrieving the maximum key if the
    root node has no entries.
    
    This does not usually happen because b-tree mappings with 0 child nodes
    are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen
    if the b-tree root node read from a device is configured that way, so fix
    this potential issue by adding a check for that case.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 17c76b0104e4 ("nilfs2: B-tree based block mapping")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Cc: Lizhi Xu <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ntb: Force physically contiguous allocation of rx ring buffers [+ + +]
Author: Dave Jiang <[email protected]>
Date:   Thu Sep 5 14:22:07 2024 -0700

    ntb: Force physically contiguous allocation of rx ring buffers
    
    [ Upstream commit 061a785a114f159e990ea8ed8d1b7dca4b41120f ]
    
    Physical addresses under IOVA on x86 platform are mapped contiguously
    as a side effect before the patch that removed CONFIG_DMA_REMAP. The
    NTB rx buffer ring is a single chunk DMA buffer that is allocated
    against the NTB PCI device. If the receive side is using a DMA device,
    then the buffers are remapped against the DMA device before being
    submitted via the dmaengine API. This scheme becomes a problem when
    the physical memory is discontiguous. When dma_map_page() is called
    on the kernel virtual address from the dma_alloc_coherent() call, the
    new IOVA mapping no longer points to all the physical memory allocated
    due to being discontiguous. Change dma_alloc_coherent() to dma_alloc_attrs()
    in order to force DMA_ATTR_FORCE_CONTIGUOUS attribute. This is the best
    fix for the circumstance. A potential future solution may be having the DMA
    mapping API providing a way to alias an existing IOVA mapping to a new
    device perhaps.
    
    This fix is not to fix the patch pointed to by the fixes tag, but to fix
    the issue arised in the ntb_transport driver on x86 platforms after the
    said patch is applied.
    
    Reported-by: Jerry Dai <[email protected]>
    Fixes: f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP")
    Tested-by: Jerry Dai <[email protected]>
    Signed-off-by: Dave Jiang <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Thu Aug 31 20:39:27 2023 +0800

    ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()
    
    [ Upstream commit e229897d373a87ee09ec5cc4ecd4bb2f895fc16b ]
    
    The debugfs_create_dir() function returns error pointers.
    It never returns NULL. So use IS_ERR() to check it.
    
    Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Reviewed-by: Dave Jiang <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ntb_perf: Fix printk format [+ + +]
Author: Max Hawking <[email protected]>
Date:   Sun Oct 8 20:45:16 2023 -0700

    ntb_perf: Fix printk format
    
    [ Upstream commit 1501ae7479c8d0f66efdbfdc9ae8d6136cefbd37 ]
    
    The correct printk format is %pa or %pap, but not %pa[p].
    
    Fixes: 99a06056124d ("NTB: ntb_perf: Fix address err in perf_copy_chunk")
    Signed-off-by: Max Hawking <[email protected]>
    Signed-off-by: Jon Mason <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvdimm: Fix devs leaks in scan_labels() [+ + +]
Author: Li Zhijian <[email protected]>
Date:   Mon Aug 19 14:20:44 2024 +0800

    nvdimm: Fix devs leaks in scan_labels()
    
    [ Upstream commit 62c2aa6b1f565d2fc1ec11a6e9e8336ce37a6426 ]
    
    scan_labels() leaks memory when label scanning fails and it falls back
    to just creating a default "seed" namespace for userspace to configure.
    Root can force the kernel to leak memory.
    
    Allocate the minimum resources unconditionally and release them when
    unneeded to avoid the memory leak.
    
    A kmemleak reports:
    unreferenced object 0xffff88800dda1980 (size 16):
      comm "kworker/u10:5", pid 69, jiffies 4294671781
      hex dump (first 16 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace (crc 0):
        [<00000000c5dea560>] __kmalloc+0x32c/0x470
        [<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm]
        [<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm]
        [<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]
        [<00000000a5f3da2e>] really_probe+0xc6/0x390
        [<00000000129e2a69>] __driver_probe_device+0x78/0x150
        [<000000002dfed28b>] driver_probe_device+0x1e/0x90
        [<00000000e7048de2>] __device_attach_driver+0x85/0x110
        [<0000000032dca295>] bus_for_each_drv+0x85/0xe0
        [<00000000391c5a7d>] __device_attach+0xbe/0x1e0
        [<0000000026dabec0>] bus_probe_device+0x94/0xb0
        [<00000000c590d936>] device_add+0x656/0x870
        [<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm]
        [<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110
        [<00000000e201f4b0>] process_one_work+0x1ee/0x600
        [<000000006d90d5a9>] worker_thread+0x183/0x350
    
    Cc: Dave Jiang <[email protected]>
    Cc: Ira Weiny <[email protected]>
    Fixes: 1b40e09a1232 ("libnvdimm: blk labels and namespace instantiation")
    Suggested-by: Dan Williams <[email protected]>
    Signed-off-by: Li Zhijian <[email protected]>
    Reviewed-by: Dan Williams <[email protected]>
    Reviewed-by: Ira Weiny <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Ira Weiny <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvme-multipath: system fails to create generic nvme device [+ + +]
Author: Hannes Reinecke <[email protected]>
Date:   Sat Sep 14 14:01:22 2024 +0200

    nvme-multipath: system fails to create generic nvme device
    
    [ Upstream commit 63bcf9014e95a7d279d10d8e2caa5d88db2b1855 ]
    
    NVME_NSHEAD_DISK_LIVE is a flag for struct nvme_ns_head, not nvme_ns.
    The current code has a typo causing NVME_NSHEAD_DISK_LIVE never to
    be cleared once device_add_disk_fails, causing the system never to
    create the 'generic' character device. Even several rescan attempts
    will change the situation and the system has to be rebooted to fix
    the issue.
    
    Fixes: 11384580e332 ("nvme-multipath: add error handling support for add_disk()")
    Signed-off-by: Hannes Reinecke <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
padata: Honor the caller's alignment in case of chunk_size 0 [+ + +]
Author: Kamlesh Gurudasani <[email protected]>
Date:   Thu Aug 22 02:32:52 2024 +0530

    padata: Honor the caller's alignment in case of chunk_size 0
    
    [ Upstream commit 24cc57d8faaa4060fd58adf810b858fcfb71a02f ]
    
    In the case where we are forcing the ps.chunk_size to be at least 1,
    we are ignoring the caller's alignment.
    
    Move the forcing of ps.chunk_size to be at least 1 before rounding it
    up to caller's alignment, so that caller's alignment is honored.
    
    While at it, use max() to force the ps.chunk_size to be at least 1 to
    improve readability.
    
    Fixes: 6d45e1c948a8 ("padata: Fix possible divide-by-0 panic in padata_mt_helper()")
    Signed-off-by: Kamlesh Gurudasani <[email protected]>
    Acked-by:  Waiman Long <[email protected]>
    Acked-by: Daniel Jordan <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

padata: use integer wrap around to prevent deadlock on seq_nr overflow [+ + +]
Author: VanGiang Nguyen <[email protected]>
Date:   Fri Aug 9 06:21:42 2024 +0000

    padata: use integer wrap around to prevent deadlock on seq_nr overflow
    
    commit 9a22b2812393d93d84358a760c347c21939029a6 upstream.
    
    When submitting more than 2^32 padata objects to padata_do_serial, the
    current sorting implementation incorrectly sorts padata objects with
    overflowed seq_nr, causing them to be placed before existing objects in
    the reorder list. This leads to a deadlock in the serialization process
    as padata_find_next cannot match padata->seq_nr and pd->processed
    because the padata instance with overflowed seq_nr will be selected
    next.
    
    To fix this, we use an unsigned integer wrap around to correctly sort
    padata objects in scenarios with integer overflow.
    
    Fixes: bfde23ce200e ("padata: unbind parallel jobs from specific CPUs")
    Cc: <[email protected]>
    Co-developed-by: Christian Gafert <[email protected]>
    Signed-off-by: Christian Gafert <[email protected]>
    Co-developed-by: Max Ferger <[email protected]>
    Signed-off-by: Max Ferger <[email protected]>
    Signed-off-by: Van Giang Nguyen <[email protected]>
    Acked-by: Daniel Jordan <[email protected]>
    Signed-off-by: Herbert Xu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
PCI: Clear the LBMS bit after a link retrain [+ + +]
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Aug 9 14:24:46 2024 +0100

    PCI: Clear the LBMS bit after a link retrain
    
    commit 8037ac08c2bbb3186f83a5a924f52d1048dbaec5 upstream.
    
    The LBMS bit, where implemented, is set by hardware either in response
    to the completion of retraining caused by writing 1 to the Retrain Link
    bit or whenever hardware has changed the link speed or width in attempt
    to correct unreliable link operation.  It is never cleared by hardware
    other than by software writing 1 to the bit position in the Link Status
    register and we never do such a write.
    
    We currently have two places, namely apply_bad_link_workaround() and
    pcie_failed_link_retrain() in drivers/pci/controller/dwc/pcie-tegra194.c
    and drivers/pci/quirks.c respectively where we check the state of the LBMS
    bit and neither is interested in the state of the bit resulting from the
    completion of retraining, both check for a link fault.
    
    And in particular pcie_failed_link_retrain() causes issues consequently, by
    trying to retrain a link where there's no downstream device anymore and the
    state of 1 in the LBMS bit has been retained from when there was a device
    downstream that has since been removed.
    
    Clear the LBMS bit then at the conclusion of pcie_retrain_link(), so that
    we have a single place that controls it and that our code can track link
    speed or width changes resulting from unreliable link operation.
    
    Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Matthew W Carlis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Cc: <[email protected]> # v6.5+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: Correct error reporting with PCIe failed link retraining [+ + +]
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Aug 9 14:24:56 2024 +0100

    PCI: Correct error reporting with PCIe failed link retraining
    
    commit 712e49c967064a3a7a5738c6f65ac540a3f6a1df upstream.
    
    Only return successful completion status from pcie_failed_link_retrain() if
    retraining has actually been done, preventing excessive delays from being
    triggered at call sites in a hope that communication will finally be
    established with the downstream device where in fact nothing has been done
    about the link in question that would justify such a hope.
    
    Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Cc: <[email protected]> # v6.5+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: dra7xx: Fix threaded IRQ request for "dra7xx-pcie-main" IRQ [+ + +]
Author: Siddharth Vadapalli <[email protected]>
Date:   Tue Aug 27 17:54:21 2024 +0530

    PCI: dra7xx: Fix threaded IRQ request for "dra7xx-pcie-main" IRQ
    
    commit 03f84b3baba7836bdfc162c19288d5ce1aa92890 upstream.
    
    Commit da87d35a6e51 ("PCI: dra7xx: Use threaded IRQ handler for
    "dra7xx-pcie-main" IRQ") switched from devm_request_irq() to
    devm_request_threaded_irq() for the "dra7xx-pcie-main" interrupt.
    
    Since the primary handler was set to NULL, the "IRQF_ONESHOT" flag
    should have also been set. Fix this.
    
    Fixes: da87d35a6e51 ("PCI: dra7xx: Use threaded IRQ handler for "dra7xx-pcie-main" IRQ")
    Suggested-by: Vignesh Raghavendra <[email protected]>
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Reported-by: Udit Kumar <[email protected]>
    Signed-off-by: Siddharth Vadapalli <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: imx6: Fix missing call to phy_power_off() in error handling [+ + +]
Author: Frank Li <[email protected]>
Date:   Mon Jul 29 16:18:10 2024 -0400

    PCI: imx6: Fix missing call to phy_power_off() in error handling
    
    commit 5b04d44d5c74e4d8aab1678496b84700b4b343fe upstream.
    
    Fix missing call to phy_power_off() in the error path of
    imx6_pcie_host_init(). Remove unnecessary check for imx6_pcie->phy
    as the PHY API already handles NULL pointers.
    
    Fixes: cbcf8722b523 ("phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Frank Li <[email protected]>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Cc: <[email protected]> # 6.1+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: keystone: Fix if-statement expression in ks_pcie_quirk() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Jul 19 18:53:26 2024 -0500

    PCI: keystone: Fix if-statement expression in ks_pcie_quirk()
    
    [ Upstream commit 6188a1c762eb9bbd444f47696eda77a5eae6207a ]
    
    This code accidentally uses && where || was intended.  It potentially
    results in a NULL dereference.
    
    Thus, fix the if-statement expression to use the correct condition.
    
    Fixes: 86f271f22bbb ("PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Dan Carpenter <[email protected]>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Siddharth Vadapalli <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() [+ + +]
Author: Alexandra Diupina <[email protected]>
Date:   Tue Sep 3 14:58:23 2024 +0300

    PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()
    
    [ Upstream commit c500a86693a126c9393e602741e348f80f1b0fc5 ]
    
    Within kirin_pcie_parse_port(), the pcie->num_slots is compared to
    pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead
    to an overflow.
    
    Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move
    pcie->num_slots increment below the if-statement to avoid out-of-bounds
    array access.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: b22dbbb24571 ("PCI: kirin: Support PERST# GPIOs for HiKey970 external PEX 8606 bridge")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Signed-off-by: Alexandra Diupina <[email protected]>
    [kwilczynski: commit log]
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: Revert to the original speed after PCIe failed link retraining [+ + +]
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Aug 9 14:24:51 2024 +0100

    PCI: Revert to the original speed after PCIe failed link retraining
    
    commit f68dea13405c94381d08f42dbf0416261622bdad upstream.
    
    When `pcie_failed_link_retrain' has failed to retrain the link by hand
    it leaves the link speed restricted to 2.5GT/s, which will then affect
    any device that has been plugged in later on, which may not suffer from
    the problem that caused the speed restriction to have been attempted.
    Consequently such a downstream device will suffer from an unnecessary
    communication throughput limitation and therefore performance loss.
    
    Remove the speed restriction then and revert the Link Control 2 register
    to its original state if link retraining with the speed restriction in
    place has failed.  Retrain the link again afterwards so as to remove any
    residual state, waiting on LT rather than DLLLA to avoid an excessive
    delay and ignoring the result as this training is supposed to fail
    anyway.
    
    Fixes: a89c82249c37 ("PCI: Work around PCIe link training failures")
    Link: https://lore.kernel.org/linux-pci/[email protected]
    Reported-by: Matthew W Carlis <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Cc: <[email protected]> # v6.5+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: Use an error code with PCIe failed link retraining [+ + +]
Author: Maciej W. Rozycki <[email protected]>
Date:   Fri Aug 9 14:25:02 2024 +0100

    PCI: Use an error code with PCIe failed link retraining
    
    commit 59100eb248c0b15585affa546c7f6834b30eb5a4 upstream.
    
    Given how the call place in pcie_wait_for_link_delay() got structured now,
    and that pcie_retrain_link() returns a potentially useful error code,
    convert pcie_failed_link_retrain() to return an error code rather than a
    boolean status, fixing handling at the call site mentioned.  Update the
    other call site accordingly.
    
    Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'")
    Link: https://lore.kernel.org/r/[email protected]
    Reported-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Maciej W. Rozycki <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Krzysztof Wilczyński <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Cc: <[email protected]> # v6.5+
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: Wait for Link before restoring Downstream Buses [+ + +]
Author: Ilpo Järvinen <[email protected]>
Date:   Thu Aug 8 15:17:07 2024 +0300

    PCI: Wait for Link before restoring Downstream Buses
    
    [ Upstream commit 3e40aa29d47e231a54640addf6a09c1f64c5b63f ]
    
    __pci_reset_bus() calls pci_bridge_secondary_bus_reset() to perform the
    reset and also waits for the Secondary Bus to become again accessible.
    __pci_reset_bus() then calls pci_bus_restore_locked() that restores the PCI
    devices connected to the bus, and if necessary, recursively restores also
    the subordinate buses and their devices.
    
    The logic in pci_bus_restore_locked() does not take into account that after
    restoring a device on one level, there might be another Link Downstream
    that can only start to come up after restore has been performed for its
    Downstream Port device. That is, the Link may require additional wait until
    it becomes accessible.
    
    Similarly, pci_slot_restore_locked() lacks wait.
    
    Amend pci_bus_restore_locked() and pci_slot_restore_locked() to wait for
    the Secondary Bus before recursively performing the restore of that bus.
    
    Fixes: 090a3c5322e9 ("PCI: Add pci_reset_slot() and pci_reset_bus()")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-nwl: Clean up clock on probe failure/removal [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri May 31 12:13:35 2024 -0400

    PCI: xilinx-nwl: Clean up clock on probe failure/removal
    
    [ Upstream commit cfd67903977b13f63340a4eb5a1cc890994f2c62 ]
    
    Make sure we turn off the clock on probe failure and device removal.
    
    Fixes: de0a01f52966 ("PCI: xilinx-nwl: Enable the clock through CCF")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Anderson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri May 31 12:13:32 2024 -0400

    PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler
    
    commit 0199d2f2bd8cd97b310f7ed82a067247d7456029 upstream.
    
    MSGF_LEG_MASK is laid out with INTA in bit 0, INTB in bit 1, INTC in bit 2,
    and INTD in bit 3. Hardware IRQ numbers start at 0, and we register
    PCI_NUM_INTX IRQs. So to enable INTA (aka hwirq 0) we should set bit 0.
    Remove the subtraction of one.
    
    This bug would cause INTx interrupts not to be delivered, as enabling INTB
    would actually enable INTA, and enabling INTA wouldn't enable anything at
    all. It is likely that this got overlooked for so long since most PCIe
    hardware uses MSIs. This fixes the following UBSAN error:
    
      UBSAN: shift-out-of-bounds in ../drivers/pci/controller/pcie-xilinx-nwl.c:389:11
      shift exponent 18446744073709551615 is too large for 32-bit type 'int'
      CPU: 1 PID: 61 Comm: kworker/u10:1 Not tainted 6.6.20+ #268
      Hardware name: xlnx,zynqmp (DT)
      Workqueue: events_unbound deferred_probe_work_func
      Call trace:
      dump_backtrace (arch/arm64/kernel/stacktrace.c:235)
      show_stack (arch/arm64/kernel/stacktrace.c:242)
      dump_stack_lvl (lib/dump_stack.c:107)
      dump_stack (lib/dump_stack.c:114)
      __ubsan_handle_shift_out_of_bounds (lib/ubsan.c:218 lib/ubsan.c:387)
      nwl_unmask_leg_irq (drivers/pci/controller/pcie-xilinx-nwl.c:389 (discriminator 1))
      irq_enable (kernel/irq/internals.h:234 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)
      __irq_startup (kernel/irq/internals.h:239 kernel/irq/chip.c:180 kernel/irq/chip.c:250)
      irq_startup (kernel/irq/chip.c:270)
      __setup_irq (kernel/irq/manage.c:1800)
      request_threaded_irq (kernel/irq/manage.c:2206)
      pcie_pme_probe (include/linux/interrupt.h:168 drivers/pci/pcie/pme.c:348)
    
    Fixes: 9a181e1093af ("PCI: xilinx-nwl: Modify IRQ chip for legacy interrupts")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Anderson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

PCI: xilinx-nwl: Fix register misspelling [+ + +]
Author: Sean Anderson <[email protected]>
Date:   Fri May 31 12:13:33 2024 -0400

    PCI: xilinx-nwl: Fix register misspelling
    
    [ Upstream commit a437027ae1730b8dc379c75fa0dd7d3036917400 ]
    
    MSIC -> MISC
    
    Fixes: c2a7ff18edcd ("PCI: xilinx-nwl: Expand error logging")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Anderson <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf annotate: Move some source code related fields from 'struct annotation' to 'struct annotated_source' [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Fri Nov 3 12:19:06 2023 -0700

    perf annotate: Move some source code related fields from 'struct annotation' to 'struct annotated_source'
    
    [ Upstream commit 0aae4c99c5f8f748c6cb5ca03bb3b3ae8cfb10df ]
    
    Some fields in the 'struct annotation' are only used with 'struct
    annotated_source' so better to be moved there in order to reduce memory
    consumption for other symbols.
    
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Christophe JAILLET <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Stable-dep-of: 3ef44458071a ("perf report: Fix --total-cycles --stdio output error")
    Signed-off-by: Sasha Levin <[email protected]>

perf annotate: Split branch stack cycles info from 'struct annotation' [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Fri Nov 3 12:19:04 2023 -0700

    perf annotate: Split branch stack cycles info from 'struct annotation'
    
    [ Upstream commit b7f87e32590bf48eca84f729d3422be7b8dc22d3 ]
    
    The cycles info is only meaningful when sample has branch stacks.  To
    save the memory for normal cases, move those fields to a new 'struct
    annotated_branch' and dynamically allocate it when needed.  Also move
    cycles_hist from annotated_source as it's related here.
    
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Christophe JAILLET <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Stable-dep-of: 3ef44458071a ("perf report: Fix --total-cycles --stdio output error")
    Signed-off-by: Sasha Levin <[email protected]>

 
perf inject: Fix leader sampling inserting additional samples [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Mon Jul 29 15:06:20 2024 -0700

    perf inject: Fix leader sampling inserting additional samples
    
    [ Upstream commit 79bcd34e0f3da39fda841406ccc957405e724852 ]
    
    The processing of leader samples would turn an individual sample with
    a group of read values into multiple samples. 'perf inject' would pass
    through the additional samples increasing the output data file size:
    
      $ perf record -g -e "{instructions,cycles}:S" -o perf.orig.data true
      $ perf script -D -i perf.orig.data | sed -e 's/perf.orig.data/perf.data/g' > orig.txt
      $ perf inject -i perf.orig.data -o perf.new.data
      $ perf script -D -i perf.new.data | sed -e 's/perf.new.data/perf.data/g' > new.txt
      $ diff -u orig.txt new.txt
      --- orig.txt    2024-07-29 14:29:40.606576769 -0700
      +++ new.txt     2024-07-29 14:30:04.142737434 -0700
      ...
      [email protected] [0x30]: event: 3
      [email protected] [0xd0]: event: 9
      +.
      +. ... raw event: size 208 bytes
      +.  0000:  09 00 00 00 01 00 d0 00 fc 72 01 86 ff ff ff ff  .........r......
      +.  0010:  74 7d 2c 00 74 7d 2c 00 fb c3 79 f9 ba d5 05 00  t},.t},...y.....
      +.  0020:  e6 cb 1a 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
      +.  0030:  02 00 00 00 00 00 00 00 76 01 00 00 00 00 00 00  ........v.......
      +.  0040:  e6 cb 1a 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      +.  0050:  62 18 00 00 00 00 00 00 f6 cb 1a 00 00 00 00 00  b...............
      +.  0060:  00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  ................
      +.  0070:  80 ff ff ff ff ff ff ff fc 72 01 86 ff ff ff ff  .........r......
      +.  0080:  f3 0e 6e 85 ff ff ff ff 0c cb 7f 85 ff ff ff ff  ..n.............
      +.  0090:  bc f2 87 85 ff ff ff ff 44 af 7f 85 ff ff ff ff  ........D.......
      +.  00a0:  bd be 7f 85 ff ff ff ff 26 d0 7f 85 ff ff ff ff  ........&.......
      +.  00b0:  6d a4 ff 85 ff ff ff ff ea 00 20 86 ff ff ff ff  m......... .....
      +.  00c0:  00 fe ff ff ff ff ff ff 57 14 4f 43 fc 7e 00 00  ........W.OC.~..
      +
      +1642373909693435 0xc550 [0xd0]: PERF_RECORD_SAMPLE(IP, 0x1): 2915700/2915700: 0xffffffff860172fc period: 1 addr: 0
      +... FP chain: nr:12
      +.....  0: ffffffffffffff80
      +.....  1: ffffffff860172fc
      +.....  2: ffffffff856e0ef3
      +.....  3: ffffffff857fcb0c
      +.....  4: ffffffff8587f2bc
      +.....  5: ffffffff857faf44
      +.....  6: ffffffff857fbebd
      +.....  7: ffffffff857fd026
      +.....  8: ffffffff85ffa46d
      +.....  9: ffffffff862000ea
      +..... 10: fffffffffffffe00
      +..... 11: 00007efc434f1457
      +... sample_read:
      +.... group nr 2
      +..... id 00000000001acbe6, value 0000000000000176, lost 0
      +..... id 00000000001acbf6, value 0000000000001862, lost 0
      +
      [email protected] [0x30]: event: 3
      ...
    
    This behavior is incorrect as in the case above 'perf inject' should
    have done nothing. Fix this behavior by disabling separating samples
    for a tool that requests it. Only request this for `perf inject` so as
    to not affect other perf tools. With the patch and the test above
    there are no differences between the orig.txt and new.txt.
    
    Fixes: e4caec0d1af3d608 ("perf evsel: Add PERF_SAMPLE_READ sample related processing")
    Signed-off-by: Ian Rogers <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf mem: Free the allocated sort string, fixing a leak [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Wed Jul 31 16:55:01 2024 -0700

    perf mem: Free the allocated sort string, fixing a leak
    
    [ Upstream commit 3da209bb1177462b6fe8e3021a5527a5a49a9336 ]
    
    The get_sort_order() returns either a new string (from strdup) or NULL
    but it never gets freed.
    
    Signed-off-by: Namhyung Kim <[email protected]>
    Fixes: 2e7f545096f954a9 ("perf mem: Factor out a function to generate sort order")
    Cc: Adrian Hunter <[email protected]>
    Cc: Athira Rajeev <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ Added Fixes tag ]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf report: Fix --total-cycles --stdio output error [+ + +]
Author: Kan Liang <[email protected]>
Date:   Tue Aug 13 09:02:00 2024 -0700

    perf report: Fix --total-cycles --stdio output error
    
    [ Upstream commit 3ef44458071a19e5b5832cdfe6f75273aa521b6e ]
    
    The --total-cycles may output wrong information with the --stdio.
    
    For example:
    
      # perf record -e "{cycles,instructions}",cache-misses -b sleep 1
      # perf report --total-cycles --stdio
    
    The total cycles output of {cycles,instructions} and cache-misses are
    almost the same.
    
      # Samples: 938  of events 'anon group { cycles, instructions }'
      # Event count (approx.): 938
      #
      # Sampled Cycles%  Sampled Cycles  Avg Cycles%  Avg Cycles  [Program Block Range]
      # ...............  ..............  ...........  ..........  ..................................................>
      #
                11.19%            2.6K        0.10%           21  [perf_iterate_ctx+48 -> >
                 5.79%            1.4K        0.45%           97  [__intel_pmu_enable_all.constprop.0+80 -> __intel_>
                 5.11%            1.2K        0.33%           71  [native_write_msr+0 ->>
    
      # Samples: 293  of event 'cache-misses'
      # Event count (approx.): 293
      #
      # Sampled Cycles%  Sampled Cycles  Avg Cycles%  Avg Cycles  [Program Block Range]
      # ...............  ..............  ...........  ..........  ..................................................>
      #
                11.19%            2.6K        0.13%           21  [perf_iterate_ctx+48 -> >
                 5.79%            1.4K        0.59%           97  [__intel_pmu_enable_all.constprop.0+80 -> __intel_>
                 5.11%            1.2K        0.43%           71  [native_write_msr+0 ->>
    
    With the symbol_conf.event_group, the 'perf report' should only report the
    block information of the leader event in a group.
    
    However, the current implementation retrieves the next event's block
    information, rather than the next group leader's block information.
    
    Make sure the index is updated even if the event is skipped.
    
    With the patch,
    
      # Samples: 293  of event 'cache-misses'
      # Event count (approx.): 293
      #
      # Sampled Cycles%  Sampled Cycles  Avg Cycles%  Avg Cycles  [Program Block Range]
      # ...............  ..............  ...........  ..........  ..................................................>
      #
               37.98%            9.0K        4.05%           299  [perf_event_addr_filters_exec+0 -> perf_event_a>
               11.19%            2.6K        0.28%            21  [perf_iterate_ctx+48 -> >
                5.79%            1.4K        1.32%            97  [__intel_pmu_enable_all.constprop.0+80 -> __intel_>
    
    Fixes: 6f7164fa231a5f36 ("perf report: Sort by sampled cycles percent per block for stdio")
    Reviewed-by: Andi Kleen <[email protected]>
    Signed-off-by: Kan Liang <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jin Yao <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf sched timehist: Fix missing free of session in perf_sched__timehist() [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Tue Aug 6 10:35:33 2024 +0800

    perf sched timehist: Fix missing free of session in perf_sched__timehist()
    
    [ Upstream commit 6bdf5168b6fb19541b0c1862bdaa596d116c7bfb ]
    
    When perf_time__parse_str() fails in perf_sched__timehist(),
    need to free session that was previously created, fix it.
    
    Fixes: 853b74071110bed3 ("perf sched timehist: Add option to specify time window of interest")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf sched timehist: Fixed timestamp error when unable to confirm event sched_in time [+ + +]
Author: Yang Jihong <[email protected]>
Date:   Mon Aug 19 10:47:20 2024 +0800

    perf sched timehist: Fixed timestamp error when unable to confirm event sched_in time
    
    [ Upstream commit 39c243411bdb8fb35777adf49ee32549633c4e12 ]
    
    If sched_in event for current task is not recorded, sched_in timestamp
    will be set to end_time of time window interest, causing an error in
    timestamp show. In this case, we choose to ignore this event.
    
    Test scenario:
    
      perf[1229608] does not record the first sched_in event, run time and sch delay are both 0
    
      # perf sched timehist
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
       2090450.763231 [0000]  perf[1229608]                       0.000      0.000      0.000
       2090450.763235 [0000]  migration/0[15]                     0.000      0.001      0.003
       2090450.763263 [0001]  perf[1229608]                       0.000      0.000      0.000
       2090450.763268 [0001]  migration/1[21]                     0.000      0.001      0.004
       2090450.763302 [0002]  perf[1229608]                       0.000      0.000      0.000
       2090450.763309 [0002]  migration/2[27]                     0.000      0.001      0.007
       2090450.763338 [0003]  perf[1229608]                       0.000      0.000      0.000
       2090450.763343 [0003]  migration/3[33]                     0.000      0.001      0.004
    
    Before:
    
      arbitrarily specify a time window of interest, timestamp will be set to an incorrect value
    
      # perf sched timehist --time 100,200
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
           200.000000 [0000]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0001]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0002]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0003]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0004]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0005]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0006]  perf[1229608]                       0.000      0.000      0.000
           200.000000 [0007]  perf[1229608]                       0.000      0.000      0.000
    
     After:
    
      # perf sched timehist --time 100,200
      Samples of sched_switch event do not have callchains.
                 time    cpu  task name                       wait time  sch delay   run time
                              [tid/pid]                          (msec)     (msec)     (msec)
      --------------- ------  ------------------------------  ---------  ---------  ---------
    
    Fixes: 853b74071110bed3 ("perf sched timehist: Add option to specify time window of interest")
    Signed-off-by: Yang Jihong <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf stat: Display iostat headers correctly [+ + +]
Author: Yicong Yang <[email protected]>
Date:   Fri Aug 2 14:58:00 2024 +0800

    perf stat: Display iostat headers correctly
    
    [ Upstream commit 2615639352420e6e3115952c5b8f46846e1c6d0e ]
    
    Currently we'll only print metric headers for metric leader in
    aggregration mode. This will make `perf iostat` header not shown
    since it'll aggregrated globally but don't have metric events:
    
      root@ubuntu204:/home/yang/linux/tools/perf# ./perf stat --iostat --timeout 1000
       Performance counter stats for 'system wide':
          port
      0000:00                    0                    0                    0                    0
      0000:80                    0                    0                    0                    0
      [...]
    
    Fix this by excluding the iostat in the check of printing metric
    headers. Then we can see the headers:
    
      root@ubuntu204:/home/yang/linux/tools/perf# ./perf stat --iostat --timeout 1000
       Performance counter stats for 'system wide':
          port             Inbound Read(MB)    Inbound Write(MB)    Outbound Read(MB)   Outbound Write(MB)
      0000:00                    0                    0                    0                    0
      0000:80                    0                    0                    0                    0
      [...]
    
    Fixes: 193a9e30207f5477 ("perf stat: Don't display metric header for non-leader uncore events")
    Signed-off-by: Yicong Yang <[email protected]>
    Acked-by: Namhyung Kim <[email protected]>
    Cc: Ian Rogers <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jonathan Cameron <[email protected]>
    Cc: Junhao He <[email protected]>
    Cc: [email protected]
    Cc: Mark Rutland <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Shameerali Kolothum Thodi <[email protected]>
    Cc: Zeng Tao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf time-utils: Fix 32-bit nsec parsing [+ + +]
Author: Ian Rogers <[email protected]>
Date:   Sat Aug 31 00:04:11 2024 -0700

    perf time-utils: Fix 32-bit nsec parsing
    
    [ Upstream commit 38e2648a81204c9fc5b4c87a8ffce93a6ed91b65 ]
    
    The "time utils" test fails in 32-bit builds:
      ...
      parse_nsec_time("18446744073.709551615")
      Failed. ptime 4294967295709551615 expected 18446744073709551615
      ...
    
    Switch strtoul to strtoull as an unsigned long in 32-bit build isn't
    64-bits.
    
    Fixes: c284d669a20d408b ("perf tools: Move parse_nsec_time to time-utils.c")
    Signed-off-by: Ian Rogers <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Alexander Shishkin <[email protected]>
    Cc: Athira Rajeev <[email protected]>
    Cc: Chaitanya S Prakash <[email protected]>
    Cc: Colin Ian King <[email protected]>
    Cc: David Ahern <[email protected]>
    Cc: Dominique Martinet <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: James Clark <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: John Garry <[email protected]>
    Cc: Junhao He <[email protected]>
    Cc: Kan Liang <[email protected]>
    Cc: Mark Rutland <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: Namhyung Kim <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Yang Jihong <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
perf ui/browser/annotate: Use global annotation_options [+ + +]
Author: Namhyung Kim <[email protected]>
Date:   Tue Nov 28 09:54:38 2023 -0800

    perf ui/browser/annotate: Use global annotation_options
    
    [ Upstream commit 22197fb296913f83c7182befd2a8b23bf042f279 ]
    
    Now it can use the global options and no need save local browser
    options separately.
    
    Reviewed-by: Ian Rogers <[email protected]>
    Signed-off-by: Namhyung Kim <[email protected]>
    Cc: Adrian Hunter <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Jiri Olsa <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
    Stable-dep-of: 3ef44458071a ("perf report: Fix --total-cycles --stdio output error")
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/arm-cmn: Ensure dtm_idx is big enough [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Mon Sep 2 18:51:59 2024 +0100

    perf/arm-cmn: Ensure dtm_idx is big enough
    
    [ Upstream commit 359414b33e00bae91e4eabf3e4ef8e76024c7673 ]
    
    While CMN_MAX_DIMENSION was bumped to 12 for CMN-650, that only supports
    up to a 10x10 mesh, so bumping dtm_idx to 256 bits at the time worked
    out OK in practice. However CMN-700 did finally support up to 144 XPs,
    and thus needs a worst-case 288 bits of dtm_idx for an aggregated XP
    event on a maxed-out config. Oops.
    
    Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support")
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/e771b358526a0d7fc06efee2c3a2fdc0c9f51d44.1725296395.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf/arm-cmn: Fail DTC counter allocation correctly [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Mon Dec 11 19:27:28 2023 +0000

    perf/arm-cmn: Fail DTC counter allocation correctly
    
    commit 1892fe103c3a20fced306c8dafa74f7f6d4ea0a3 upstream.
    
    Calling arm_cmn_event_clear() before all DTC indices are allocated is
    wrong, and can lead to arm_cmn_event_add() erroneously clearing live
    counters from full DTCs where allocation fails. Since the DTC counters
    are only updated by arm_cmn_init_counter() after all DTC and DTM
    allocations succeed, nothing actually needs cleaning up in this case
    anyway, and it should just return directly as it did before.
    
    Fixes: 7633ec2c262f ("perf/arm-cmn: Rework DTC counters (again)")
    Signed-off-by: Robin Murphy <[email protected]>
    Reviewed-by: Ilkka Koskinen <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/ed589c0d8e4130dc68b8ad1625226d28bdc185d4.1702322847.git.robin.murphy@arm.com
    Signed-off-by: Catalin Marinas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

perf/arm-cmn: Fix CCLA register offset [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Mon Sep 2 18:51:58 2024 +0100

    perf/arm-cmn: Fix CCLA register offset
    
    [ Upstream commit 88b63a82c84ed9bbcbdefb10cb6f75dd1dd04887 ]
    
    Apparently pmu_event_sel is offset by 8 for all CCLA nodes, not just
    the CCLA_RNI combination type.
    
    Fixes: 23760a014417 ("perf/arm-cmn: Add CMN-700 support")
    Acked-by: Mark Rutland <[email protected]>
    Reviewed-by: Ilkka Koskinen <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/6e7bb06fef6046f83e7647aad0e5be544139763f.1725296395.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf/arm-cmn: Improve debugfs pretty-printing for large configs [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Wed Dec 13 16:24:07 2023 +0000

    perf/arm-cmn: Improve debugfs pretty-printing for large configs
    
    [ Upstream commit a1083ee717e9bde012268782e084d343314490a4 ]
    
    The debugfs pretty-printer was written for the CMN-600 assumptions of a
    maximum 8x8 mesh, but CMN-700 now allows coordinates and ID values up to
    12 and 128 respectively, which can overflow the format strings, mess up
    the alignment of the table and hurt overall readability. This table does
    prove useful for double-checking that the driver is picking up the
    topology of new systems correctly and for verifying user expectations,
    so tweak the formatting to stay nice and readable with wider values.
    
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/1d1517eadd1bac5992fab679c9dc531b381944da.1702484646.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Stable-dep-of: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.")
    Signed-off-by: Sasha Levin <[email protected]>

perf/arm-cmn: Refactor node ID handling. Again. [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Mon Sep 2 18:51:57 2024 +0100

    perf/arm-cmn: Refactor node ID handling. Again.
    
    [ Upstream commit e79634b53e398966c49f803c49701bc74dc3ccf8 ]
    
    The scope of the "extra device ports" configuration is not made clear by
    the CMN documentation - so far we've assumed it applies globally, based
    on the sole example which suggests as much. However it transpires that
    this is incorrect, and the format does in fact vary based on each
    individual XP's port configuration. As a consequence, we're currenly
    liable to decode the port/device indices from a node ID incorrectly,
    thus program the wrong event source in the DTM leading to bogus event
    counts, and also show device topology on the wrong ports in debugfs.
    
    To put this right, rework node IDs yet again to carry around the
    additional data necessary to decode them properly per-XP. At this point
    the notion of fully decomposing an ID becomes more impractical than it's
    worth, so unabstracting the XY mesh coordinates (where 2/3 users were
    just debug anyway) ends up leaving things a bit simpler overall.
    
    Fixes: 60d1504070c2 ("perf/arm-cmn: Support new IP features")
    Acked-by: Mark Rutland <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/5195f990152fc37adba5fbf5929a6b11063d9f09.1725296395.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

perf/arm-cmn: Rework DTC counters (again) [+ + +]
Author: Robin Murphy <[email protected]>
Date:   Fri Oct 20 18:51:26 2023 +0100

    perf/arm-cmn: Rework DTC counters (again)
    
    [ Upstream commit 7633ec2c262fab3e7c5bf3cd3876b5748f584a57 ]
    
    The bitmap-based scheme for tracking DTC counter usage turns out to be a
    complete dead-end for its imagined purpose, since by the time we have to
    keep track of a per-DTC counter index anyway, we already have enough
    information to make the bitmap itself redundant. Revert the remains of
    it back to almost the original scheme, but now expanded to track per-DTC
    indices, in preparation for making use of them in anger.
    
    Note that since cycle count events always use a dedicated counter on a
    single DTC, we reuse the field to encode their DTC index directly.
    
    Signed-off-by: Robin Murphy <[email protected]>
    Reviewed-by: Ilkka Koskinen <[email protected]>
    Link: https://lore.kernel.org/r/5f6ade76b47f033836d7a36c03555da896dfb4a3.1697824215.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Stable-dep-of: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.")
    Signed-off-by: Sasha Levin <[email protected]>

 
perf/x86/intel/pt: Fix sampling synchronization [+ + +]
Author: Adrian Hunter <[email protected]>
Date:   Mon Jul 15 19:07:00 2024 +0300

    perf/x86/intel/pt: Fix sampling synchronization
    
    commit d92792a4b26e50b96ab734cbe203d8a4c932a7a9 upstream.
    
    pt_event_snapshot_aux() uses pt->handle_nmi to determine if tracing
    needs to be stopped, however tracing can still be going because
    pt->handle_nmi is set to zero before tracing is stopped in pt_event_stop,
    whereas pt_event_snapshot_aux() requires that tracing must be stopped in
    order to copy a sample of trace from the buffer.
    
    Instead call pt_config_stop() always, which anyway checks config for
    RTIT_CTL_TRACEEN and does nothing if it is already clear.
    
    Note pt_event_snapshot_aux() can continue to use pt->handle_nmi to
    determine if the trace needs to be restarted afterwards.
    
    Fixes: 25e8920b301c ("perf/x86/intel/pt: Add sampling support")
    Signed-off-by: Adrian Hunter <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function [+ + +]
Author: Wang Jianzheng <[email protected]>
Date:   Thu Aug 29 14:48:23 2024 +0800

    pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function
    
    [ Upstream commit c25478419f6fd3f74c324a21ec007cf14f2688d7 ]
    
    When an error occurs during the execution of the function
    __devinit_dove_pinctrl_probe, the clk is not properly disabled.
    
    Fix this by calling clk_disable_unprepare before return.
    
    Fixes: ba607b6238a1 ("pinctrl: mvebu: make pdma clock on dove mandatory")
    Signed-off-by: Wang Jianzheng <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: single: fix missing error code in pcs_probe() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Mon Aug 19 10:46:25 2024 +0800

    pinctrl: single: fix missing error code in pcs_probe()
    
    [ Upstream commit cacd8cf79d7823b07619865e994a7916fcc8ae91 ]
    
    If pinctrl_enable() fails in pcs_probe(), it should return the error code.
    
    Fixes: 8f773bfbdd42 ("pinctrl: single: fix possible memory leak when pinctrl_enable() fails")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: ti: iodelay: Use scope based of_node_put() cleanups [+ + +]
Author: Peng Fan <[email protected]>
Date:   Thu Jun 27 21:17:19 2024 +0800

    pinctrl: ti: iodelay: Use scope based of_node_put() cleanups
    
    [ Upstream commit 791a8bb202a85f707c20ef04a471519e35f089dc ]
    
    Use scope based of_node_put() cleanup to simplify code.
    
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Jonathan Cameron <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Stable-dep-of: a9f2b249adee ("pinctrl: ti: ti-iodelay: Fix some error handling paths")
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: ti: ti-iodelay: Convert to platform remove callback returning void [+ + +]
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Oct 9 10:38:56 2023 +0200

    pinctrl: ti: ti-iodelay: Convert to platform remove callback returning void
    
    [ Upstream commit 93650550dff9d1a3b88c553f8adb81dc89778977 ]
    
    The .remove() callback for a platform driver returns an int which makes
    many driver authors wrongly assume it's possible to do error handling by
    returning an error code. However the value returned is ignored (apart
    from emitting a warning) and this typically results in resource leaks.
    
    To improve here there is a quest to make the remove callback return
    void. In the first step of this quest all drivers are converted to
    .remove_new(), which already returns void. Eventually after all drivers
    are converted, .remove_new() will be renamed to .remove().
    
    Trivially convert this driver from always returning zero in the remove
    callback to the void returning variant.
    
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Stable-dep-of: a9f2b249adee ("pinctrl: ti: ti-iodelay: Fix some error handling paths")
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: ti: ti-iodelay: Fix some error handling paths [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Tue Jul 9 22:37:43 2024 +0200

    pinctrl: ti: ti-iodelay: Fix some error handling paths
    
    [ Upstream commit a9f2b249adeef2b9744a884355fa8f5e581d507f ]
    
    In the probe, if an error occurs after the ti_iodelay_pinconf_init_dev()
    call, it is likely that ti_iodelay_pinconf_deinit_dev() should be called,
    as already done in the remove function.
    
    Also in ti_iodelay_pinconf_init_dev(), if an error occurs after the first
    regmap_update_bits() call, it is also likely that the deinit() function
    should be called.
    
    The easier way to fix it is to add a devm_add_action_or_reset() at the
    rigtht place to have ti_iodelay_pinconf_deinit_dev() called when needed.
    
    Doing so, the .remove() function can be removed, and the associated
    platform_set_drvdata() call in the probe as well.
    
    Fixes: 003910ebc83b ("pinctrl: Introduce TI IOdelay configuration driver")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Link: https://lore.kernel.org/0220fa5b925bd08e361be8206a5438f6229deaac.1720556038.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pinctrl: Use device_get_match_data() [+ + +]
Author: Rob Herring <[email protected]>
Date:   Mon Oct 9 12:29:13 2023 -0500

    pinctrl: Use device_get_match_data()
    
    [ Upstream commit 63bffc2d3a99eaabc786c513eea71be3f597f175 ]
    
    Use preferred device_get_match_data() instead of of_match_device() to
    get the driver match data. With this, adjust the includes to explicitly
    include the correct headers.
    
    Signed-off-by: Rob Herring <[email protected]>
    Reviewed-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Stable-dep-of: a9f2b249adee ("pinctrl: ti: ti-iodelay: Fix some error handling paths")
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: pm:cpupower: Add missing powercap_set_enabled() stub function [+ + +]
Author: John B. Wyatt IV <[email protected]>
Date:   Wed Sep 4 22:19:08 2024 -0400

    pm:cpupower: Add missing powercap_set_enabled() stub function
    
    [ Upstream commit 4b80294fb53845dc5c98cca0c989da09150f2ca9 ]
    
    There was a symbol listed in the powercap.h file that was not implemented.
    Implement it with a stub return of 0.
    
    Programs like SWIG require that functions that are defined in the
    headers be implemented.
    
    Fixes: c2294c1496b7 ("cpupower: Introduce powercap intel-rapl library and powercap-info command")
    Suggested-by: Shuah Khan <[email protected]>
    Signed-off-by: John B. Wyatt IV <[email protected]>
    Signed-off-by: John B. Wyatt IV <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
pmdomain: core: Harden inter-column space in debug summary [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Wed Sep 4 16:30:45 2024 +0200

    pmdomain: core: Harden inter-column space in debug summary
    
    [ Upstream commit 692c20c4d075bd452acfbbc68200fc226c7c9496 ]
    
    The inter-column space in the debug summary is two spaces.  However, in
    one case, the extra space is handled implicitly in a field width
    specifier.  Make inter-column space explicit to ease future maintenance.
    
    Fixes: 45fbc464b047 ("PM: domains: Add "performance" column to debug summary")
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Link: https://lore.kernel.org/r/ae61eb363621b981edde878e1e74d701702a579f.1725459707.git.geert+renesas@glider.be
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
power: supply: axp20x_battery: Remove design from min and max voltage [+ + +]
Author: Chris Morgan <[email protected]>
Date:   Wed Aug 21 16:54:43 2024 -0500

    power: supply: axp20x_battery: Remove design from min and max voltage
    
    [ Upstream commit 61978807b00f8a1817b0e5580981af1cd2f428a5 ]
    
    The POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN and
    POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN values should be immutable
    properties of the battery, but for this driver they are writable values
    and used as the minimum and maximum values for charging. Remove the
    DESIGN designation from these values.
    
    Fixes: 46c202b5f25f ("power: supply: add battery driver for AXP20X and AXP22X PMICs")
    Suggested-by: Chen-Yu Tsai <[email protected]>
    Signed-off-by: Chris Morgan <[email protected]>
    Acked-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense [+ + +]
Author: Artur Weber <[email protected]>
Date:   Sat Aug 17 12:51:14 2024 +0200

    power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense
    
    [ Upstream commit 3a3acf839b2cedf092bdd1ff65b0e9895df1656b ]
    
    Commit 223a3b82834f ("power: supply: max17042_battery: use VFSOC for
    capacity when no rsns") made it so that capacity on systems without
    current sensing would be read from VFSOC instead of RepSOC. However,
    the SOC threshold calculation still read RepSOC to get the SOC
    regardless of the current sensing option state.
    
    Fix this by applying the same conditional to determine which register
    should be read.
    
    This also seems to be the intended behavior as per the datasheet - SOC
    alert config value in MiscCFG on setups without current sensing is set
    to a value of 0b11, indicating SOC alerts being generated based on
    VFSOC, instead of 0b00 which indicates SOC alerts being generated based
    on RepSOC.
    
    This fixes an issue on the Galaxy S3/Midas boards, where the alert
    interrupt would be constantly retriggered, causing high CPU usage
    on idle (around ~12%-15%).
    
    Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC")
    Signed-off-by: Artur Weber <[email protected]>
    Reviewed-by: Henrik Grimler <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sebastian Reichel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powercap: intel_rapl: Fix off by one in get_rpi() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Aug 20 11:41:34 2024 +0300

    powercap: intel_rapl: Fix off by one in get_rpi()
    
    [ Upstream commit 95f6580352a7225e619551febb83595bcb77ab17 ]
    
    The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have
    NR_RAPL_PRIMITIVES number of elements.  Thus the > needs to be >=
    to prevent an off by one access.
    
    Fixes: 98ff639a7289 ("powercap: intel_rapl: Support per Interface primitive information")
    Signed-off-by: Dan Carpenter <[email protected]>
    Acked-by: Zhang Rui <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/8xx: Fix initial memory mapping [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Tue Aug 20 19:23:45 2024 +0200

    powerpc/8xx: Fix initial memory mapping
    
    [ Upstream commit f9f2bff64c2f0dbee57be3d8c2741357ad3d05e6 ]
    
    Commit cf209951fa7f ("powerpc/8xx: Map linear memory with huge pages")
    introduced an initial mapping of kernel TEXT using PAGE_KERNEL_TEXT,
    but the pages that contain kernel TEXT may also contain kernel RODATA,
    and depending on selected debug options PAGE_KERNEL_TEXT may be either
    RWX or ROX. RODATA must be writable during init because it also
    contains ro_after_init data.
    
    So use PAGE_KERNEL_X instead to be sure it is RWX.
    
    Fixes: cf209951fa7f ("powerpc/8xx: Map linear memory with huge pages")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/dac7a828d8497c4548c91840575a706657baa4f1.1724173828.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

powerpc/8xx: Fix kernel vs user address comparison [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Tue Aug 20 19:23:46 2024 +0200

    powerpc/8xx: Fix kernel vs user address comparison
    
    [ Upstream commit 65a82e117ffeeab0baf6f871a1cab11a28ace183 ]
    
    Since commit 9132a2e82adc ("powerpc/8xx: Define a MODULE area below
    kernel text"), module exec space is below PAGE_OFFSET so not only
    space above PAGE_OFFSET, but space above TASK_SIZE need to be seen
    as kernel space.
    
    Until now the problem went undetected because by default TASK_SIZE
    is 0x8000000 which means address space is determined by just
    checking upper address bit. But when TASK_SIZE is over 0x80000000,
    PAGE_OFFSET is used for comparison, leading to thinking module
    addresses are part of user space.
    
    Fix it by using TASK_SIZE instead of PAGE_OFFSET for address
    comparison.
    
    Fixes: 9132a2e82adc ("powerpc/8xx: Define a MODULE area below kernel text")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/3f574c9845ff0a023b46cb4f38d2c45aecd769bd.1724173828.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc/atomic: Use YZ constraints for DS-form instructions [+ + +]
Author: Michael Ellerman <[email protected]>
Date:   Mon Sep 16 22:05:10 2024 +1000

    powerpc/atomic: Use YZ constraints for DS-form instructions
    
    commit 39190ac7cff1fd15135fa8e658030d9646fdb5f2 upstream.
    
    The 'ld' and 'std' instructions require a 4-byte aligned displacement
    because they are DS-form instructions. But the "m" asm constraint
    doesn't enforce that.
    
    That can lead to build errors if the compiler chooses a non-aligned
    displacement, as seen with GCC 14:
    
      /tmp/ccuSzwiR.s: Assembler messages:
      /tmp/ccuSzwiR.s:2579: Error: operand out of domain (39 is not a multiple of 4)
      make[5]: *** [scripts/Makefile.build:229: net/core/page_pool.o] Error 1
    
    Dumping the generated assembler shows:
    
      ld 8,39(8)       # MEM[(const struct atomic64_t *)_29].counter, t
    
    Use the YZ constraints to tell the compiler either to generate a DS-form
    displacement, or use an X-form instruction, either of which prevents the
    build error.
    
    See commit 2d43cc701b96 ("powerpc/uaccess: Fix build errors seen with
    GCC 13/14") for more details on the constraint letters.
    
    Fixes: 9f0cbea0d8cc ("[POWERPC] Implement atomic{, 64}_{read, write}() without volatile")
    Cc: [email protected] # v2.6.24+
    Reported-by: Stephen Rothwell <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]
    Tested-by: Mina Almasry <[email protected]>
    Reviewed-by: Segher Boessenkool <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/vdso: Inconditionally use CFUNC macro [+ + +]
Author: Christophe Leroy <[email protected]>
Date:   Thu Aug 22 10:00:29 2024 +0200

    powerpc/vdso: Inconditionally use CFUNC macro
    
    [ Upstream commit 65948b0e716a47382731889ee6bbb18642b8b003 ]
    
    During merge of commit 4e991e3c16a3 ("powerpc: add CFUNC assembly
    label annotation") a fallback version of CFUNC macro was added at
    the last minute, so it can be used inconditionally.
    
    Fixes: 4e991e3c16a3 ("powerpc: add CFUNC assembly label annotation")
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://msgid.link/0fa863f2f69b2ca4094ae066fcf1430fb31110c9.1724313540.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin <[email protected]>

 
pps: add an error check in parport_attach [+ + +]
Author: Ma Ke <[email protected]>
Date:   Wed Aug 28 21:18:14 2024 +0800

    pps: add an error check in parport_attach
    
    [ Upstream commit 62c5a01a5711c8e4be8ae7b6f0db663094615d48 ]
    
    In parport_attach, the return value of ida_alloc is unchecked, witch leads
    to the use of an invalid index value.
    
    To address this issue, index should be checked. When the index value is
    abnormal, the device should be freed.
    
    Found by code review, compile tested only.
    
    Cc: [email protected]
    Fixes: fb56d97df70e ("pps: client: use new parport device model")
    Signed-off-by: Ma Ke <[email protected]>
    Acked-by: Rodolfo Giometti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

pps: remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Sun Apr 14 12:10:17 2024 +0200

    pps: remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit 55dbc5b5174d0e7d1fa397d05aa4cb145e8b887e ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    This is less verbose.
    
    Link: https://lkml.kernel.org/r/9f681747d446b874952a892491387d79ffe565a9.1713089394.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Christophe JAILLET <[email protected]>
    Cc: Rodolfo Giometti <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 62c5a01a5711 ("pps: add an error check in parport_attach")
    Signed-off-by: Sasha Levin <[email protected]>

 
r8169: disable ALDPS per default for RTL8125 [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Wed Sep 11 15:51:11 2024 +0200

    r8169: disable ALDPS per default for RTL8125
    
    [ Upstream commit b9c7ac4fe22c608acf6153a3329df2b6b6cd416c ]
    
    En-Wei reported that traffic breaks if cable is unplugged for more
    than 3s and then re-plugged. This was supposed to be fixed by
    621735f59064 ("r8169: fix rare issue with broken rx after link-down on
    RTL8125"). But apparently this didn't fix the issue for everybody.
    The 3s threshold rang a bell, as this is the delay after which ALDPS
    kicks in. And indeed disabling ALDPS fixes the issue for this user.
    Maybe this fixes the issue in general. In a follow-up step we could
    remove the first fix attempt and see whether anybody complains.
    
    Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
    Tested-by: En-Wei WU <[email protected]>
    Signed-off-by: Heiner Kallweit <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu/nocb: Fix RT throttling hrtimer armed from offline CPU [+ + +]
Author: Frederic Weisbecker <[email protected]>
Date:   Wed Aug 14 00:56:40 2024 +0200

    rcu/nocb: Fix RT throttling hrtimer armed from offline CPU
    
    [ Upstream commit 9139f93209d1ffd7f489ab19dee01b7c3a1a43d2 ]
    
    After a CPU is marked offline and until it reaches its final trip to
    idle, rcuo has several opportunities to be woken up, either because
    a callback has been queued in the meantime or because
    rcutree_report_cpu_dead() has issued the final deferred NOCB wake up.
    
    If RCU-boosting is enabled, RCU kthreads are set to SCHED_FIFO policy.
    And if RT-bandwidth is enabled, the related hrtimer might be armed.
    However this then happens after hrtimers have been migrated at the
    CPUHP_AP_HRTIMERS_DYING stage, which is broken as reported by the
    following warning:
    
     Call trace:
      enqueue_hrtimer+0x7c/0xf8
      hrtimer_start_range_ns+0x2b8/0x300
      enqueue_task_rt+0x298/0x3f0
      enqueue_task+0x94/0x188
      ttwu_do_activate+0xb4/0x27c
      try_to_wake_up+0x2d8/0x79c
      wake_up_process+0x18/0x28
      __wake_nocb_gp+0x80/0x1a0
      do_nocb_deferred_wakeup_common+0x3c/0xcc
      rcu_report_dead+0x68/0x1ac
      cpuhp_report_idle_dead+0x48/0x9c
      do_idle+0x288/0x294
      cpu_startup_entry+0x34/0x3c
      secondary_start_kernel+0x138/0x158
    
    Fix this with waking up rcuo using an IPI if necessary. Since the
    existing API to deal with this situation only handles swait queue, rcuo
    is only woken up from offline CPUs if it's not already waiting on a
    grace period. In the worst case some callbacks will just wait for a
    grace period to complete before being assigned to a subsequent one.
    
    Reported-by: "Cheng-Jui Wang (王正睿)" <[email protected]>
    Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
    Signed-off-by: Frederic Weisbecker <[email protected]>
    Signed-off-by: Neeraj Upadhyay <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/cxgb4: Added NULL check for lookup_atid [+ + +]
Author: Mikhail Lobanov <[email protected]>
Date:   Thu Sep 12 10:58:39 2024 -0400

    RDMA/cxgb4: Added NULL check for lookup_atid
    
    [ Upstream commit e766e6a92410ca269161de059fff0843b8ddd65f ]
    
    The lookup_atid() function can return NULL if the ATID is
    invalid or does not exist in the identifier table, which
    could lead to dereferencing a null pointer without a
    check in the `act_establish()` and `act_open_rpl()` functions.
    Add a NULL check to prevent null pointer dereferencing.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
    Signed-off-by: Mikhail Lobanov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/erdma: Return QP state in erdma_query_qp [+ + +]
Author: Cheng Xu <[email protected]>
Date:   Mon Sep 2 19:29:20 2024 +0800

    RDMA/erdma: Return QP state in erdma_query_qp
    
    [ Upstream commit e77127ff6416b17e0b3e630ac46ee5c9a6570f57 ]
    
    Fix qp_state and cur_qp_state to return correct values in
    struct ib_qp_attr.
    
    Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation")
    Signed-off-by: Cheng Xu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/hns: Don't modify rq next block addr in HIP09 QPC [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Fri Sep 6 17:34:36 2024 +0800

    RDMA/hns: Don't modify rq next block addr in HIP09 QPC
    
    [ Upstream commit 6928d264e328e0cb5ee7663003a6e46e4cba0a7e ]
    
    The field 'rq next block addr' in QPC can be updated by driver only
    on HIP08. On HIP09 HW updates this field while driver is not allowed.
    
    Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Sep 6 17:34:42 2024 +0800

    RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS
    
    [ Upstream commit ce196f6297c7f3ab7780795e40efd6c521f60c8b ]
    
    The 1bit-ECC recovery address read from HW only contain bits 64:12, so
    it should be fixed left-shifted 12 bits when used.
    
    Currently, the driver will shift the address left by PAGE_SHIFT when
    used, which is wrong in non-4K OS.
    
    Fixes: 2de949abd6a5 ("RDMA/hns: Recover 1bit-ECC error of RAM on chip")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix restricted __le16 degrades to integer issue [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Mon Sep 9 14:53:31 2024 +0800

    RDMA/hns: Fix restricted __le16 degrades to integer issue
    
    [ Upstream commit f4ccc0a2a0c5977540f519588636b5bc81aae2db ]
    
    Fix sparse warnings: restricted __le16 degrades to integer.
    
    Fixes: 5a87279591a1 ("RDMA/hns: Support hns HW stats")
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled [+ + +]
Author: Chengchang Tang <[email protected]>
Date:   Fri Sep 6 17:34:40 2024 +0800

    RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled
    
    [ Upstream commit 74d315b5af180220d561684d15897730135733a6 ]
    
    Fix missuse of spin_lock_irq()/spin_unlock_irq() when
    spin_lock_irqsave()/spin_lock_irqrestore() was hold.
    
    This was discovered through the lock debugging, and the corresponding
    log is as follows:
    
    raw_local_irq_restore() called with IRQs enabled
    WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
    ...
    Call trace:
     warn_bogus_irq_restore+0x30/0x40
     _raw_spin_unlock_irqrestore+0x84/0xc8
     add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
     hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
     hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
     create_qp+0x138/0x258
     ib_create_qp_kernel+0x50/0xe8
     create_mad_qp+0xa8/0x128
     ib_mad_port_open+0x218/0x448
     ib_mad_init_device+0x70/0x1f8
     add_client_context+0xfc/0x220
     enable_device_and_get+0xd0/0x140
     ib_register_device.part.0+0xf4/0x1c8
     ib_register_device+0x34/0x50
     hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
     hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
     __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
     hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]
    
    Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
    Signed-off-by: Chengchang Tang <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range() [+ + +]
Author: wenglianfa <[email protected]>
Date:   Fri Sep 6 17:34:39 2024 +0800

    RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()
    
    [ Upstream commit d586628b169d14bbf36be64d2b3ec9d9d2fe0432 ]
    
    The max value of 'unit' and 'hop_num' is 2^24 and 2, so the value of
    'step' may exceed the range of u32. Change the type of 'step' to u64.
    
    Fixes: 38389eaa4db1 ("RDMA/hns: Add mtr support for mixed multihop addressing")
    Signed-off-by: wenglianfa <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 [+ + +]
Author: wenglianfa <[email protected]>
Date:   Fri Sep 6 17:34:37 2024 +0800

    RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08
    
    [ Upstream commit fd8489294dd2beefb70f12ec4f6132aeec61a4d0 ]
    
    Currently rsv_qp is freed before ib_unregister_device() is called
    on HIP08. During the time interval, users can still dereg MR and
    rsv_qp will be used in this process, leading to a UAF. Move the
    release of rsv_qp after calling ib_unregister_device() to fix it.
    
    Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
    Signed-off-by: wenglianfa <[email protected]>
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Fri Sep 6 17:34:41 2024 +0800

    RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler
    
    [ Upstream commit 4321feefa5501a746ebf6a7d8b59e6b955ae1860 ]
    
    In abnormal interrupt handler, a PF reset will be triggered even if
    the device is a VF. It should be a VF reset.
    
    Fixes: 2b9acb9a97fe ("RDMA/hns: Add the process of AEQ overflow for hip08")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/hns: Optimize hem allocation performance [+ + +]
Author: Junxian Huang <[email protected]>
Date:   Fri Sep 6 17:34:43 2024 +0800

    RDMA/hns: Optimize hem allocation performance
    
    [ Upstream commit fe51f6254d81f5a69c31df16353d6539b2b51630 ]
    
    When allocating MTT hem, for each hop level of each hem that is being
    allocated, the driver iterates the hem list to find out whether the
    bt page has been allocated in this hop level. If not, allocate a new
    one and splice it to the list. The time complexity is O(n^2) in worst
    cases.
    
    Currently the allocation for-loop uses 'unit' as the step size. This
    actually has taken into account the reuse of last-hop-level MTT bt
    pages by multiple buffer pages. Thus pages of last hop level will
    never have been allocated, so there is no need to iterate the hem list
    in last hop level.
    
    Removing this unnecessary iteration can reduce the time complexity to
    O(n).
    
    Fixes: 38389eaa4db1 ("RDMA/hns: Add mtr support for mixed multihop addressing")
    Signed-off-by: Junxian Huang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/irdma: fix error message in irdma_modify_qp_roce() [+ + +]
Author: Vitaliy Shevtsov <[email protected]>
Date:   Mon Sep 16 21:58:05 2024 +0500

    RDMA/irdma: fix error message in irdma_modify_qp_roce()
    
    [ Upstream commit 9f0eafe86ea0a589676209d0cff1a1ed49a037d3 ]
    
    Use a correct field max_dest_rd_atomic instead of max_rd_atomic for the
    error output.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
    Signed-off-by: Vitaliy Shevtsov <[email protected]>
    Link: https://lore.kernel.org/stable/20240916165817.14691-1-v.shevtsov%40maxima.ru
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency [+ + +]
Author: Zhu Yanjun <[email protected]>
Date:   Tue Aug 20 13:33:36 2024 +0200

    RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency
    
    [ Upstream commit 86dfdd8288907f03c18b7fb462e0e232c4f98d89 ]
    
    In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
    destroying CM IDs"), the function flush_workqueue is invoked to flush the
    work queue iwcm_wq.
    
    But at that time, the work queue iwcm_wq was created via the function
    alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.
    
    Because the current process is trying to flush the whole iwcm_wq, if
    iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
    process is not reclaiming memory or running on a workqueue which doesn't
    have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
    leading to a deadlock.
    
    The call trace is as below:
    
    [  125.350876][ T1430] Call Trace:
    [  125.356281][ T1430]  <TASK>
    [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
    [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
    [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
    [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
    [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
    [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
    [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
    [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
    [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
    [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
    [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
    [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
    [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
    [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
    [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
    [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
    [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
    [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
    [ 125.531837][ T1430] kthread (kernel/kthread.c:389)
    [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
    [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
    [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
    [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
    [  125.566487][ T1430]  </TASK>
    [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---
    
    Fixes: aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs")
    Link: https://patch.msgid.link/r/[email protected]
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Tested-by: kernel test robot <[email protected]>
    Signed-off-by: Zhu Yanjun <[email protected]>
    Reviewed-by: Bart Van Assche <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache [+ + +]
Author: Michael Guralnik <[email protected]>
Date:   Tue Sep 3 14:24:49 2024 +0300

    RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache
    
    [ Upstream commit ee6d57a2e13d11ce9050cfc3e3b69ef707a44a63 ]
    
    When searching the MR cache for suitable cache entries, don't use mkeys
    larger than twice the size required for the MR.
    This should ensure the usage of mkeys closer to the minimal required size
    and reduce memory waste.
    
    On driver init we create entries for mkeys with clear attributes and
    powers of 2 sizes from 4 to the max supported size.
    This solves the issue for anyone using mkeys that fit these
    requirements.
    
    In the use case where an MR is registered with different attributes,
    like an access flag we can't UMR, we'll create a new cache entry to store
    it upon dereg.
    Without this fix, any later registration with same attributes and smaller
    size will use the newly created cache entry and it's mkeys, disregarding
    the memory waste of using mkeys larger than required.
    
    For example, one worst-case scenario can be when registering and
    deregistering a 1GB mkey with ATS enabled which will cause the creation of
    a new cache entry to hold those type of mkeys. A user registering a 4k MR
    with ATS will end up using the new cache entry and an mkey that can
    support a 1GB MR, thus wasting x250k memory than actually needed in the HW.
    
    Additionally, allow all small registration to use the smallest size
    cache entry that is initialized on driver load even if size is larger
    than twice the required size.
    
    Fixes: 73d09b2fe833 ("RDMA/mlx5: Introduce mlx5r_cache_rb_key")
    Signed-off-by: Michael Guralnik <[email protected]>
    Link: https://patch.msgid.link/8ba3a6e3748aace2026de8b83da03aba084f78f4.1725362530.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Obtain upper net device only when needed [+ + +]
Author: Mark Bloch <[email protected]>
Date:   Mon Sep 9 20:30:20 2024 +0300

    RDMA/mlx5: Obtain upper net device only when needed
    
    [ Upstream commit 3ed7f9e239938a0cfaf3689e2f545229ecabec06 ]
    
    Report the upper device's state as the RDMA port state only in RoCE LAG or
    switchdev LAG.
    
    Fixes: 27f9e0ccb6da ("net/mlx5: Lag, Add single RDMA device in multiport mode")
    Signed-off-by: Mark Bloch <[email protected]>
    Signed-off-by: Michael Guralnik <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reviewed-by: Kalesh AP <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds [+ + +]
Author: Md Haris Iqbal <[email protected]>
Date:   Wed Aug 21 13:22:12 2024 +0200

    RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds
    
    [ Upstream commit 3e4289b29e216a55d08a89e126bc0b37cbad9f38 ]
    
    In the function init_conns(), after the create_con() and create_cm() for
    loop if something fails. In the cleanup for loop after the destroy tag, we
    access out of bound memory because cid is set to clt_path->s.con_num.
    
    This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds
    in the cleanup loop later.
    
    Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
    Signed-off-by: Md Haris Iqbal <[email protected]>
    Signed-off-by: Jack Wang <[email protected]>
    Signed-off-by: Grzegorz Prajsner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer [+ + +]
Author: Jack Wang <[email protected]>
Date:   Wed Aug 21 13:22:10 2024 +0200

    RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer
    
    [ Upstream commit 3258cbbd86deaa2675e1799bc3d18bd1ef472641 ]
    
    Reset hb_missed_cnt after receiving traffic from other peer, so
    hb is more robust again high load on host or network.
    
    Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality")
    Signed-off-by: Jack Wang <[email protected]>
    Signed-off-by: Md Haris Iqbal <[email protected]>
    Signed-off-by: Grzegorz Prajsner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: Return actual error in of_regulator_bulk_get_all() [+ + +]
Author: Chen-Yu Tsai <[email protected]>
Date:   Thu Aug 22 15:20:45 2024 +0800

    regulator: Return actual error in of_regulator_bulk_get_all()
    
    [ Upstream commit 395a41a1d3e377462f3eea8a205ee72be8885ff6 ]
    
    If regulator_get() in of_regulator_bulk_get_all() returns an error, that
    error gets overridden and -EINVAL is always passed out. This masks probe
    deferral requests and likely won't work properly in all cases.
    
    Fix this by letting of_regulator_bulk_get_all() return the original
    error code.
    
    Fixes: 27b9ecc7a9ba ("regulator: Add of_regulator_bulk_get_all")
    Signed-off-by: Chen-Yu Tsai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
remoteproc: imx_rproc: Correct ddr alias for i.MX8M [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Jul 19 16:36:11 2024 +0800

    remoteproc: imx_rproc: Correct ddr alias for i.MX8M
    
    [ Upstream commit c901f817792822eda9cec23814a4621fa3e66695 ]
    
    The DDR Alias address should be 0x40000000 according to RM, so correct
    it.
    
    Fixes: 4ab8f9607aad ("remoteproc: imx_rproc: support i.MX8MQ/M")
    Reported-by: Terry Lv <[email protected]>
    Reviewed-by: Iuliana Prodan <[email protected]>
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

remoteproc: imx_rproc: Initialize workqueue earlier [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Jul 19 16:36:13 2024 +0800

    remoteproc: imx_rproc: Initialize workqueue earlier
    
    [ Upstream commit 858e57c1d3dd7b92cc0fa692ba130a0a5d57e49d ]
    
    Initialize workqueue before requesting mailbox channel, otherwise if
    mailbox interrupt comes before workqueue ready, the imx_rproc_rx_callback
    will trigger issue.
    
    Fixes: 2df7062002d0 ("remoteproc: imx_proc: enable virtio/mailbox")
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Daniel Baluta <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mathieu Poirier <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Remove *.orig pattern from .gitignore [+ + +]
Author: Laurent Pinchart <[email protected]>
Date:   Mon Jul 29 18:57:38 2024 +0300

    Remove *.orig pattern from .gitignore
    
    commit 76be4f5a784533c71afbbb1b8f2963ef9e2ee258 upstream.
    
    Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej
    patterns to .gitignore in v2.6.23. The commit message didn't give a
    rationale. Later on, commit 1f5d3a6b6532 ("Remove *.rej pattern from
    .gitignore") removed the *.rej pattern in v2.6.26, on the rationale that
    *.rej files indicated something went really wrong and should not be
    ignored.
    
    The *.rej files are now shown by `git status`, which helps located
    conflicts when applying patches and lowers the probability that they
    will go unnoticed. It is however still easy to overlook the *.orig files
    which slowly polute the source tree. That's not as big of a deal as not
    noticing a conflict, but it's still not nice.
    
    Drop the *.orig pattern from .gitignore to avoid this and help keep the
    source tree clean.
    
    Signed-off-by: Laurent Pinchart <[email protected]>
    [[email protected]:
    I do not have a strong opinion about this. Perhaps some people may have
    a different opinion.
    
    If you are someone who wants to ignore *.orig, it is likely you would
    want to do so across all projects. Then, $XDG_CONFIG_HOME/git/ignore
    would be more suitable for your needs. gitignore(5) suggests, "Patterns
    which a user wants Git to ignore in all situations generally go into a
    file specified by core.excludesFile in the user's ~/.gitconfig".
    
    Please note that you cannot do the opposite; if *.orig is ignored by
    the project's .gitignore, you cannot override the decision because
    $XDG_CONFIG_HOME/git/ignore has a lower priority.
    
    If *.orig is sitting on the fence, I'd leave it to the users. ]
    Signed-off-by: Masahiro Yamada <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
reset: berlin: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 16:14:24 2024 +0200

    reset: berlin: fix OF node leak in probe() error path
    
    [ Upstream commit 5f58a88cc91075be38cec69b7cb70aaa4ba69e8b ]
    
    Driver is leaking OF node reference on memory allocation failure.
    Acquire the OF node reference after memory allocation to fix this and
    keep it simple.
    
    Fixes: aed6f3cadc86 ("reset: berlin: convert to a platform driver")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Philipp Zabel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

reset: k210: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 16:14:25 2024 +0200

    reset: k210: fix OF node leak in probe() error path
    
    [ Upstream commit b14e40f5dc7cd0dd7e958010e6ca9ad32ff2ddad ]
    
    Driver is leaking OF node reference on memory allocation failure.
    Acquire the OF node reference after memory allocation to fix this and
    keep it simple.
    
    Fixes: 5a2308da9f60 ("riscv: Add Canaan Kendryte K210 reset controller")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Reviewed-by: Damien Le Moal <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Philipp Zabel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "dm: requeue IO if mapping table not yet available" [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Fri Sep 13 15:05:18 2024 +0200

    Revert "dm: requeue IO if mapping table not yet available"
    
    [ Upstream commit c8691cd0fc11197515ed148de0780d927bfca38b ]
    
    This reverts commit fa247089de9936a46e290d4724cb5f0b845600f5.
    
    The following sequence of commands causes a livelock - there will be
    workqueue process looping and consuming 100% CPU:
    
    dmsetup create --notable test
    truncate -s 1MiB testdata
    losetup /dev/loop0 testdata
    dmsetup load test --table '0 2048 linear /dev/loop0 0'
    dd if=/dev/zero of=/dev/dm-0 bs=16k count=1 conv=fdatasync
    
    The livelock is caused by the commit fa247089de99. The commit claims that
    it fixes a race condition, however, it is unknown what the actual race
    condition is and what program is involved in the race condition.
    
    When the inactive table is loaded, the nodes /dev/dm-0 and
    /sys/block/dm-0 are created. /dev/dm-0 has zero size at this point. When
    the device is suspended and resumed, the nodes /dev/mapper/test and
    /dev/disk/* are created.
    
    If some program opens a block device before it is created by dmsetup or
    lvm, the program is buggy, so dm could just report an error as it used to
    do before.
    
    Reported-by: Zdenek Kabelac <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Fixes: fa247089de99 ("dm: requeue IO if mapping table not yet available")
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "media: tuners: fix error return code of hybrid_tuner_request_state()" [+ + +]
Author: Roman Smirnov <[email protected]>
Date:   Tue Jul 16 12:10:40 2024 +0300

    Revert "media: tuners: fix error return code of hybrid_tuner_request_state()"
    
    commit e25cc4be4616fcf5689622b3226d648aab253cdb upstream.
    
    This reverts commit b9302fa7ed979e84b454e4ca92192cf485a4ed41.
    
    As Fedor Pchelkin pointed out, this commit violates the
    convention of using the macro return value, which causes errors.
    For example, in functions tda18271_attach(), xc5000_attach(),
    simple_tuner_attach().
    
    Link: https://lore.kernel.org/linux-media/20240424202031.syigrtrtipbq5f2l@fpc/
    Suggested-by: Fedor Pchelkin <[email protected]>
    Signed-off-by: Roman Smirnov <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "net: libwx: fix alloc msix vectors failed" [+ + +]
Author: Duanqiang Wen <[email protected]>
Date:   Mon Sep 30 15:33:27 2024 +0800

    Revert "net: libwx: fix alloc msix vectors failed"
    
    This reverts commit 69197dfc64007b5292cc960581548f41ccd44828.
    commit 937d46ecc5f9 ("net: wangxun: add ethtool_ops for
    channel number") changed NIC misc irq from most significant
    bit to least significant bit, the former condition is not
    required to apply this patch, because we only need to set
    irq affinity for NIC queue irq vectors.
    this patch is required after commit 937d46ecc5f9 ("net: wangxun:
    add ethtool_ops for channel number") was applied, so this is only
    relevant to 6.6.y branch.
    
    Signed-off-by: Duanqiang Wen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible" [+ + +]
Author: Dmitry Baryshkov <[email protected]>
Date:   Mon Jul 29 22:52:14 2024 +0300

    Revert "soc: qcom: smd-rpm: Match rpmsg channel instead of compatible"
    
    commit b17155133391d7f6dd18d3fb94a7d492fdec18fa upstream.
    
    The rpm_requests device nodes have the compatible node. As such the
    rpmsg core uses OF modalias instead of a native rpmsg modalias. Thus if
    smd-rpm is built as a module, it doesn't get autoloaded for the device.
    
    Revert the commit bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel
    instead of compatible")
    
    Fixes: bcabe1e09135 ("soc: qcom: smd-rpm: Match rpmsg channel instead of compatible")
    Cc: [email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bjorn Andersson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert: "dm-verity: restart or panic on an I/O error" [+ + +]
Author: Mikulas Patocka <[email protected]>
Date:   Wed Oct 2 15:56:18 2024 +0200

    Revert: "dm-verity: restart or panic on an I/O error"
    
    commit 462763212dd71c41f092b48eaa352bc1f5ed5d66 upstream.
    
    This reverts commit e6a3531dd542cb127c8de32ab1e54a48ae19962b.
    
    The problem that the commit e6a3531dd542cb127c8de32ab1e54a48ae19962b
    fixes was reported as a security bug, but Google engineers working on
    Android and ChromeOS didn't want to change the default behavior, they
    want to get -EIO rather than restarting the system, so I am reverting
    that commit.
    
    Note also that calling machine_restart from the I/O handling code is
    potentially unsafe (the reboot notifiers may wait for the bio that
    triggered the restart), but Android uses the reboot notifiers to store
    the reboot reason into the PMU microcontroller, so machine_restart must
    be used.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Cc: [email protected]
    Fixes: e6a3531dd542 ("dm-verity: restart or panic on an I/O error")
    Suggested-by: Sami Tolvanen <[email protected]>
    Suggested-by: Will Drewry <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
RISC-V: KVM: Allow legacy PMU access from guest [+ + +]
Author: Atish Patra <[email protected]>
Date:   Fri Aug 16 00:08:08 2024 -0700

    RISC-V: KVM: Allow legacy PMU access from guest
    
    [ Upstream commit 7d1ffc8b087e97dbe1985912c7a2d00e53cea169 ]
    
    Currently, KVM traps & emulates PMU counter access only if SBI PMU
    is available as the guest can only configure/read PMU counters via
    SBI only. However, if SBI PMU is not enabled in the host, the
    guest will fallback to the legacy PMU which will try to access
    cycle/instret and result in an illegal instruction trap which
    is not desired.
    
    KVM can allow dummy emulation of cycle/instret only for the guest
    if SBI PMU is not enabled in the host. The dummy emulation will
    still return zero as we don't to expose the host counter values
    from a guest using legacy PMU.
    
    Fixes: a9ac6c37521f ("RISC-V: KVM: Implement trap & emulate for hpmcounters")
    Signed-off-by: Atish Patra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RISC-V: KVM: Fix sbiret init before forwarding to userspace [+ + +]
Author: Andrew Jones <[email protected]>
Date:   Wed Aug 7 17:49:44 2024 +0200

    RISC-V: KVM: Fix sbiret init before forwarding to userspace
    
    [ Upstream commit 6b7b282e6baea06ba65b55ae7d38326ceb79cebf ]
    
    When forwarding SBI calls to userspace ensure sbiret.error is
    initialized to SBI_ERR_NOT_SUPPORTED first, in case userspace
    neglects to set it to anything. If userspace neglects it then we
    can't be sure it did anything else either, so we just report it
    didn't do or try anything. Just init sbiret.value to zero, which is
    the preferred value to return when nothing special is specified.
    
    KVM was already initializing both sbiret.error and sbiret.value, but
    the values used appear to come from a copy+paste of the __sbi_ecall()
    implementation, i.e. a0 and a1, which don't apply prior to the call
    being executed, nor at all when forwarding to userspace.
    
    Fixes: dea8ee31a039 ("RISC-V: KVM: Add SBI v0.1 support")
    Signed-off-by: Andrew Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RISC-V: KVM: Fix to allow hpmcounter31 from the guest [+ + +]
Author: Atish Patra <[email protected]>
Date:   Fri Aug 16 00:08:09 2024 -0700

    RISC-V: KVM: Fix to allow hpmcounter31 from the guest
    
    [ Upstream commit 5aa09297a3dcc798d038bd7436f8c90f664045a6 ]
    
    The csr_fun defines a count parameter which defines the total number
    CSRs emulated in KVM starting from the base. This value should be
    equal to total number of counters possible for trap/emulation (32).
    
    Fixes: a9ac6c37521f ("RISC-V: KVM: Implement trap & emulate for hpmcounters")
    Signed-off-by: Atish Patra <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Anup Patel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
riscv: Fix fp alignment bug in perf_callchain_user() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Jul 8 11:28:46 2024 +0800

    riscv: Fix fp alignment bug in perf_callchain_user()
    
    [ Upstream commit 22ab08955ea13be04a8efd20cc30890e0afaa49c ]
    
    The standard RISC-V calling convention said:
            "The stack grows downward and the stack pointer is always
            kept 16-byte aligned".
    
    So perf_callchain_user() should check whether 16-byte aligned for fp.
    
    Link: https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
    
    Fixes: dbeb90b0c1eb ("riscv: Add perf callchain support")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Cc: Björn Töpel <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Palmer Dabbelt <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
samples/bpf: Fix compilation errors with cf-protection option [+ + +]
Author: Jiangshan Yi <[email protected]>
Date:   Thu Aug 15 21:55:24 2024 +0800

    samples/bpf: Fix compilation errors with cf-protection option
    
    [ Upstream commit fdf1c728fac541891ef1aa773bfd42728626769c ]
    
    Currently, compiling the bpf programs will result the compilation errors
    with the cf-protection option as follows in arm64 and loongarch64 machine
    when using gcc 12.3.1 and clang 17.0.6. This commit fixes the compilation
    errors by limited the cf-protection option only used in x86 platform.
    
    [root@localhost linux]# make M=samples/bpf
            ......
      CLANG-bpf  samples/bpf/xdp2skb_meta_kern.o
    error: option 'cf-protection=return' cannot be specified on this target
    error: option 'cf-protection=branch' cannot be specified on this target
    2 errors generated.
      CLANG-bpf  samples/bpf/syscall_tp_kern.o
    error: option 'cf-protection=return' cannot be specified on this target
    error: option 'cf-protection=branch' cannot be specified on this target
    2 errors generated.
            ......
    
    Fixes: 34f6e38f58db ("samples/bpf: fix warning with ignored-attributes")
    Reported-by: Jiangshan Yi <[email protected]>
    Signed-off-by: Jiangshan Yi <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Tested-by: Qiang Wang <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy [+ + +]
Author: Tianchen Ding <[email protected]>
Date:   Wed Jun 26 10:35:05 2024 +0800

    sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy
    
    [ Upstream commit faa42d29419def58d3c3e5b14ad4037f0af3b496 ]
    
    Consider the following cgroup:
    
                           root
                            |
                 ------------------------
                 |                      |
           normal_cgroup            idle_cgroup
                 |                      |
       SCHED_IDLE task_A           SCHED_NORMAL task_B
    
    According to the cgroup hierarchy, A should preempt B. But current
    check_preempt_wakeup_fair() treats cgroup se and task separately, so B
    will preempt A unexpectedly.
    Unify the wakeup logic by {c,p}se_is_idle only. This makes SCHED_IDLE of
    a task a relative policy that is effective only within its own cgroup,
    similar to the behavior of NICE.
    
    Also fix se_is_idle() definition when !CONFIG_FAIR_GROUP_SCHED.
    
    Fixes: 304000390f88 ("sched: Cgroup SCHED_IDLE support")
    Signed-off-by: Tianchen Ding <[email protected]>
    Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
    Reviewed-by: Josh Don <[email protected]>
    Reviewed-by: Vincent Guittot <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
sched/numa: Complete scanning of inactive VMAs when there is no alternative [+ + +]
Author: Mel Gorman <[email protected]>
Date:   Tue Oct 10 09:31:43 2023 +0100

    sched/numa: Complete scanning of inactive VMAs when there is no alternative
    
    [ Upstream commit f169c62ff7cd1acf8bac8ae17bfeafa307d9e6fa ]
    
    VMAs are skipped if there is no recent fault activity but this represents
    a chicken-and-egg problem as there may be no fault activity if the PTEs
    are never updated to trap NUMA hints. There is an indirect reliance on
    scanning to be forced early in the lifetime of a task but this may fail
    to detect changes in phase behaviour. Force inactive VMAs to be scanned
    when all other eligible VMAs have been updated within the same scan
    sequence.
    
    Test results in general look good with some changes in performance, both
    negative and positive, depending on whether the additional scanning and
    faulting was beneficial or not to the workload. The autonuma benchmark
    workload NUMA01_THREADLOCAL was picked for closer examination. The workload
    creates two processes with numerous threads and thread-local storage that
    is zero-filled in a loop. It exercises the corner case where unrelated
    threads may skip VMAs that are thread-local to another thread and still
    has some VMAs that inactive while the workload executes.
    
    The VMA skipping activity frequency with and without the patch:
    
            6.6.0-rc2-sched-numabtrace-v1
            =============================
                649 reason=scan_delay
              9,094 reason=unsuitable
             48,915 reason=shared_ro
            143,919 reason=inaccessible
            193,050 reason=pid_inactive
    
            6.6.0-rc2-sched-numabselective-v1
            =============================
                146 reason=seq_completed
                622 reason=ignore_pid_inactive
    
                624 reason=scan_delay
              6,570 reason=unsuitable
             16,101 reason=shared_ro
             27,608 reason=inaccessible
             41,939 reason=pid_inactive
    
    Note that with the patch applied, the PID activity is ignored
    (ignore_pid_inactive) to ensure a VMA with some activity is completely
    scanned. In addition, a small number of VMAs are scanned when no other
    eligible VMA is available during a single scan window (seq_completed).
    The number of times a VMA is skipped due to no PID activity from the
    scanning task (pid_inactive) drops dramatically. It is expected that
    this will increase the number of PTEs updated for NUMA hinting faults
    as well as hinting faults but these represent PTEs that would otherwise
    have been missed. The tradeoff is scan+fault overhead versus improving
    locality due to migration.
    
    On a 2-socket Cascade Lake test machine, the time to complete the
    workload is as follows;
    
                                                     6.6.0-rc2              6.6.0-rc2
                                           sched-numabtrace-v1 sched-numabselective-v1
      Min       elsp-NUMA01_THREADLOCAL      174.22 (   0.00%)      117.64 (  32.48%)
      Amean     elsp-NUMA01_THREADLOCAL      175.68 (   0.00%)      123.34 *  29.79%*
      Stddev    elsp-NUMA01_THREADLOCAL        1.20 (   0.00%)        4.06 (-238.20%)
      CoeffVar  elsp-NUMA01_THREADLOCAL        0.68 (   0.00%)        3.29 (-381.70%)
      Max       elsp-NUMA01_THREADLOCAL      177.18 (   0.00%)      128.03 (  27.74%)
    
    The time to complete the workload is reduced by almost 30%:
    
                         6.6.0-rc2   6.6.0-rc2
                      sched-numabtrace-v1 sched-numabselective-v1 /
      Duration User       91201.80    63506.64
      Duration System      2015.53     1819.78
      Duration Elapsed     1234.77      868.37
    
    In this specific case, system CPU time was not increased but it's not
    universally true.
    
    From vmstat, the NUMA scanning and fault activity is as follows;
    
                                            6.6.0-rc2      6.6.0-rc2
                                  sched-numabtrace-v1 sched-numabselective-v1
      Ops NUMA base-page range updates       64272.00    26374386.00
      Ops NUMA PTE updates                   36624.00       55538.00
      Ops NUMA PMD updates                      54.00       51404.00
      Ops NUMA hint faults                   15504.00       75786.00
      Ops NUMA hint local faults %           14860.00       56763.00
      Ops NUMA hint local percent               95.85          74.90
      Ops NUMA pages migrated                 1629.00     6469222.00
    
    Both the number of PTE updates and hint faults is dramatically
    increased. While this is superficially unfortunate, it represents
    ranges that were simply skipped without the patch. As a result
    of the scanning and hinting faults, many more pages were also
    migrated but as the time to completion is reduced, the overhead
    is offset by the gain.
    
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Raghavendra K T <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Complete scanning of partial VMAs regardless of PID activity [+ + +]
Author: Mel Gorman <[email protected]>
Date:   Tue Oct 10 09:31:42 2023 +0100

    sched/numa: Complete scanning of partial VMAs regardless of PID activity
    
    [ Upstream commit b7a5b537c55c088d891ae554103d1b281abef781 ]
    
    NUMA Balancing skips VMAs when the current task has not trapped a NUMA
    fault within the VMA. If the VMA is skipped then mm->numa_scan_offset
    advances and a task that is trapping faults within the VMA may never
    fully update PTEs within the VMA.
    
    Force tasks to update PTEs for partially scanned PTEs. The VMA will
    be tagged for NUMA hints by some task but this removes some of the
    benefit of tracking PID activity within a VMA. A follow-on patch
    will mitigate this problem.
    
    The test cases and machines evaluated did not trigger the corner case so
    the performance results are neutral with only small changes within the
    noise from normal test-to-test variance. However, the next patch makes
    the corner case easier to trigger.
    
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Tested-by: Raghavendra K T <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Document vma_numab_state fields [+ + +]
Author: Mel Gorman <[email protected]>
Date:   Tue Oct 10 09:31:38 2023 +0100

    sched/numa: Document vma_numab_state fields
    
    [ Upstream commit 9ae5c00ea2e600a8b823f9b95606dd244f3096bf ]
    
    Document the intended usage of the fields.
    
    [ mingo: Reformatted to take less vertical space & tidied it up. ]
    
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Fix the vma scan starving issue [+ + +]
Author: Yujie Liu <[email protected]>
Date:   Tue Aug 27 19:29:58 2024 +0800

    sched/numa: Fix the vma scan starving issue
    
    [ Upstream commit f22cde4371f3c624e947a35b075c06c771442a43 ]
    
    Problem statement:
    Since commit fc137c0ddab2 ("sched/numa: enhance vma scanning logic"), the
    Numa vma scan overhead has been reduced a lot.  Meanwhile, the reducing of
    the vma scan might create less Numa page fault information.  The
    insufficient information makes it harder for the Numa balancer to make
    decision.  Later, commit b7a5b537c55c08 ("sched/numa: Complete scanning of
    partial VMAs regardless of PID activity") and commit 84db47ca7146d7
    ("sched/numa: Fix mm numa_scan_seq based unconditional scan") are found to
    bring back part of the performance.
    
    Recently when running SPECcpu omnetpp_r on a 320 CPUs/2 Sockets system, a
    long duration of remote Numa node read was observed by PMU events: A few
    cores having ~500MB/s remote memory access for ~20 seconds.  It causes
    high core-to-core variance and performance penalty.  After the
    investigation, it is found that many vmas are skipped due to the active
    PID check.  According to the trace events, in most cases,
    vma_is_accessed() returns false because the history access info stored in
    pids_active array has been cleared.
    
    Proposal:
    The main idea is to adjust vma_is_accessed() to let it return true easier.
    Thus compare the diff between mm->numa_scan_seq and
    vma->numab_state->prev_scan_seq.  If the diff has exceeded the threshold,
    scan the vma.
    
    This patch especially helps the cases where there are small number of
    threads, like the process-based SPECcpu.  Without this patch, if the
    SPECcpu process access the vma at the beginning, then sleeps for a long
    time, the pid_active array will be cleared.  A a result, if this process
    is woken up again, it never has a chance to set prot_none anymore.
    Because only the first 2 times of access is granted for vma scan:
    (current->mm->numa_scan_seq) - vma->numab_state->start_scan_seq) < 2 to be
    worse, no other threads within the task can help set the prot_none.  This
    causes information lost.
    
    Raghavendra helped test current patch and got the positive result
    on the AMD platform:
    
    autonumabench NUMA01
                                base                  patched
    Amean     syst-NUMA01      194.05 (   0.00%)      165.11 *  14.92%*
    Amean     elsp-NUMA01      324.86 (   0.00%)      315.58 *   2.86%*
    
    Duration User      380345.36   368252.04
    Duration System      1358.89     1156.23
    Duration Elapsed     2277.45     2213.25
    
    autonumabench NUMA02
    
    Amean     syst-NUMA02        1.12 (   0.00%)        1.09 *   2.93%*
    Amean     elsp-NUMA02        3.50 (   0.00%)        3.56 *  -1.84%*
    
    Duration User        1513.23     1575.48
    Duration System         8.33        8.13
    Duration Elapsed       28.59       29.71
    
    kernbench
    
    Amean     user-256    22935.42 (   0.00%)    22535.19 *   1.75%*
    Amean     syst-256     7284.16 (   0.00%)     7608.72 *  -4.46%*
    Amean     elsp-256      159.01 (   0.00%)      158.17 *   0.53%*
    
    Duration User       68816.41    67615.74
    Duration System     21873.94    22848.08
    Duration Elapsed      506.66      504.55
    
    Intel 256 CPUs/2 Sockets:
    autonuma benchmark also shows improvements:
    
                                                   v6.10-rc5              v6.10-rc5
                                                                             +patch
    Amean     syst-NUMA01                  245.85 (   0.00%)      230.84 *   6.11%*
    Amean     syst-NUMA01_THREADLOCAL      205.27 (   0.00%)      191.86 *   6.53%*
    Amean     syst-NUMA02                   18.57 (   0.00%)       18.09 *   2.58%*
    Amean     syst-NUMA02_SMT                2.63 (   0.00%)        2.54 *   3.47%*
    Amean     elsp-NUMA01                  517.17 (   0.00%)      526.34 *  -1.77%*
    Amean     elsp-NUMA01_THREADLOCAL       99.92 (   0.00%)      100.59 *  -0.67%*
    Amean     elsp-NUMA02                   15.81 (   0.00%)       15.72 *   0.59%*
    Amean     elsp-NUMA02_SMT               13.23 (   0.00%)       12.89 *   2.53%*
    
                       v6.10-rc5   v6.10-rc5
                                      +patch
    Duration User     1064010.16  1075416.23
    Duration System      3307.64     3104.66
    Duration Elapsed     4537.54     4604.73
    
    The SPECcpu remote node access issue disappears with the patch applied.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: fc137c0ddab2 ("sched/numa: enhance vma scanning logic")
    Signed-off-by: Chen Yu <[email protected]>
    Co-developed-by: Chen Yu <[email protected]>
    Signed-off-by: Yujie Liu <[email protected]>
    Reported-by: Xiaoping Zhou <[email protected]>
    Reviewed-and-tested-by: Raghavendra K T <[email protected]>
    Acked-by: Mel Gorman <[email protected]>
    Cc: "Chen, Tim C" <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: Juri Lelli <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Raghavendra K T <[email protected]>
    Cc: Vincent Guittot <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Move up the access pid reset logic [+ + +]
Author: Raghavendra K T <[email protected]>
Date:   Tue Oct 10 09:31:41 2023 +0100

    sched/numa: Move up the access pid reset logic
    
    [ Upstream commit 2e2675db1906ac04809f5399bf1f5e30d56a6f3e ]
    
    Recent NUMA hinting faulting activity is reset approximately every
    VMA_PID_RESET_PERIOD milliseconds. However, if the current task has not
    accessed a VMA then the reset check is missed and the reset is potentially
    deferred forever. Check if the PID activity information should be reset
    before checking if the current task recently trapped a NUMA hinting fault.
    
    [ [email protected]: Rewrite changelog ]
    
    Suggested-by: Mel Gorman <[email protected]>
    Signed-off-by: Raghavendra K T <[email protected]>
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Rename vma_numab_state::access_pids[] => ::pids_active[], ::next_pid_reset => ::pids_active_reset [+ + +]
Author: Mel Gorman <[email protected]>
Date:   Tue Oct 10 09:31:39 2023 +0100

    sched/numa: Rename vma_numab_state::access_pids[] => ::pids_active[], ::next_pid_reset => ::pids_active_reset
    
    [ Upstream commit f3a6c97940fbd25d6c84c2d5642338fc99a9b35b ]
    
    The access_pids[] field name is somewhat ambiguous as no PIDs are accessed.
    Similarly, it's not clear that next_pid_reset is related to access_pids[].
    Rename the fields to more accurately reflect their purpose.
    
    [ mingo: Rename in the comments too. ]
    
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

sched/numa: Trace decisions related to skipping VMAs [+ + +]
Author: Mel Gorman <[email protected]>
Date:   Tue Oct 10 09:31:40 2023 +0100

    sched/numa: Trace decisions related to skipping VMAs
    
    [ Upstream commit ed2da8b725b932b1e2b2f4835bb664d47ed03031 ]
    
    NUMA balancing skips or scans VMAs for a variety of reasons. In preparation
    for completing scans of VMAs regardless of PID access, trace the reasons
    why a VMA was skipped. In a later patch, the tracing will be used to track
    if a VMA was forcibly scanned.
    
    Signed-off-by: Mel Gorman <[email protected]>
    Signed-off-by: Ingo Molnar <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue")
    Signed-off-by: Sasha Levin <[email protected]>

 
scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Thu Aug 15 14:29:05 2024 +0300

    scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()
    
    [ Upstream commit 2e4b02fad094976763af08fec2c620f4f8edd9ae ]
    
    The kref_put() function will call nport->release if the refcount drops to
    zero.  The nport->release release function is _efc_nport_free() which frees
    "nport".  But then we dereference "nport" on the next line which is a use
    after free.  Re-order these lines to avoid the use after free.
    
    Fixes: fcd427303eb9 ("scsi: elx: libefc: SLI and FC PORT state machine interfaces")
    Signed-off-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Daniel Wagner <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: mac_scsi: Disallow bus errors during PDMA send [+ + +]
Author: Finn Thain <[email protected]>
Date:   Wed Aug 7 13:36:28 2024 +1000

    scsi: mac_scsi: Disallow bus errors during PDMA send
    
    commit 5551bc30e4a69ad86d0d008e2f56cd59b6583476 upstream.
    
    SD cards can produce write latency spikes on the order of a hundred
    milliseconds. If the target firmware does not hide that latency during DATA
    IN and OUT phases it can cause the PDMA circuitry to raise a processor bus
    fault which in turn leads to an unreliable byte count and a DMA overrun.
    
    The Last Byte Sent flag is used to detect the overrun but this mechanism is
    unreliable on some systems. Instead, set a DID_ERROR result whenever there
    is a bus fault during a PDMA send, unless the cause was a phase mismatch.
    
    Cc: [email protected] # 5.15+
    Reported-and-tested-by: Stan Johnson <[email protected]>
    Fixes: 7c1f3e3447a1 ("scsi: mac_scsi: Treat Last Byte Sent time-out as failure")
    Signed-off-by: Finn Thain <[email protected]>
    Link: https://lore.kernel.org/r/cc38df687ace2c4ffc375a683b2502fc476b600d.1723001788.git.fthain@linux-m68k.org
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: mac_scsi: Refactor polling loop [+ + +]
Author: Finn Thain <[email protected]>
Date:   Wed Aug 7 13:36:28 2024 +1000

    scsi: mac_scsi: Refactor polling loop
    
    commit 5545c3165cbc98615fe65a44f41167cbb557e410 upstream.
    
    Before the error handling can be revised, some preparation is needed.
    Refactor the polling loop with a new function, macscsi_wait_for_drq().
    This function will gain more call sites in the next patch.
    
    Cc: [email protected] # 5.15+
    Tested-by: Stan Johnson <[email protected]>
    Signed-off-by: Finn Thain <[email protected]>
    Link: https://lore.kernel.org/r/6a5ffabb4290c0d138c6d285fda8fa3902e926f0.1723001788.git.fthain@linux-m68k.org
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages [+ + +]
Author: Finn Thain <[email protected]>
Date:   Wed Aug 7 13:36:28 2024 +1000

    scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages
    
    commit 5ec4f820cb9766e4583df947150a6febce8da794 upstream.
    
    After a bus fault, capture and log the chip registers immediately, if the
    NDEBUG_PSEUDO_DMA macro is defined. Remove some printk(KERN_DEBUG ...)
    messages that aren't needed any more.  Don't skip the debug message when
    bytes == 0. Show all of the byte counters in the debug messages.
    
    Cc: [email protected] # 5.15+
    Tested-by: Stan Johnson <[email protected]>
    Signed-off-by: Finn Thain <[email protected]>
    Link: https://lore.kernel.org/r/7573c79f4e488fc00af2b8a191e257ca945e0409.1723001788.git.fthain@linux-m68k.org
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: NCR5380: Check for phase match during PDMA fixup [+ + +]
Author: Finn Thain <[email protected]>
Date:   Wed Aug 7 13:36:28 2024 +1000

    scsi: NCR5380: Check for phase match during PDMA fixup
    
    [ Upstream commit 5768718da9417331803fc4bc090544c2a93b88dc ]
    
    It's not an error for a target to change the bus phase during a transfer.
    Unfortunately, the FLAG_DMA_FIXUP workaround does not allow for that -- a
    phase change produces a DRQ timeout error and the device borken flag will
    be set.
    
    Check the phase match bit during FLAG_DMA_FIXUP processing. Don't forget to
    decrement the command residual. While we are here, change shost_printk()
    into scmd_printk() for better consistency with other DMA error messages.
    
    Tested-by: Stan Johnson <[email protected]>
    Fixes: 55181be8ced1 ("ncr5380: Replace redundant flags with FLAG_NO_DMA_FIXUP")
    Signed-off-by: Finn Thain <[email protected]>
    Link: https://lore.kernel.org/r/99dc7d1f4c825621b5b120963a69f6cd3e9ca659.1723001788.git.fthain@linux-m68k.org
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: sd: Fix off-by-one error in sd_read_block_characteristics() [+ + +]
Author: Martin Wilck <[email protected]>
Date:   Thu Sep 12 15:43:08 2024 +0200

    scsi: sd: Fix off-by-one error in sd_read_block_characteristics()
    
    commit f81eaf08385ddd474a2f41595a7757502870c0eb upstream.
    
    Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for
    example), sd_read_block_characteristics() may attempt an out-of-bounds
    memory access when accessing the zoned field at offset 8.
    
    Fixes: 7fb019c46eee ("scsi: sd: Switch to using scsi_device VPD pages")
    Cc: [email protected]
    Signed-off-by: Martin Wilck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly [+ + +]
Author: Gilbert Wu <[email protected]>
Date:   Thu Jul 11 14:47:02 2024 -0500

    scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly
    
    [ Upstream commit f1393d52e6cda9c20f12643cbecf1e1dc357e0e2 ]
    
    Correct a rare multipath failure issue by reverting commit 94a68c814328
    ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") [1].
    
    Reason for revert: The patch propagated the path failure to SML quickly
    when one of the path fails during IO and AIO path gets disabled for a
    multipath device.
    
    But it created a new issue: when creating a volume on an encryption-enabled
    controller, the firmware reports the AIO path is disabled, which cause the
    driver to report a path failure to SML for a multipath device.
    
    There will be a new fix to handle "Illegal request" and "Invalid field in
    parameter list" on RAID path when the AIO path is disabled on a multipath
    device.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Fixes: 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer")
    Reviewed-by: Scott Benesh <[email protected]>
    Reviewed-by: Scott Teel <[email protected]>
    Reviewed-by: Mike McGowen <[email protected]>
    Signed-off-by: Gilbert Wu <[email protected]>
    Signed-off-by: Don Brace <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: qcom: Update MODE_MAX cfg_bw value [+ + +]
Author: Manish Pandey <[email protected]>
Date:   Tue Sep 3 12:07:09 2024 +0530

    scsi: ufs: qcom: Update MODE_MAX cfg_bw value
    
    commit 0c40f079f1c808e7e480c795a79009f200366eb1 upstream.
    
    Commit 8db8f6ce556a ("scsi: ufs: qcom: Add missing interconnect bandwidth
    values for Gear 5") updated the ufs_qcom_bw_table for Gear 5. However, it
    missed updating the cfg_bw value for the max mode.
    
    Hence update the cfg_bw value for the max mode for UFS 4.x devices.
    
    Fixes: 8db8f6ce556a ("scsi: ufs: qcom: Add missing interconnect bandwidth values for Gear 5")
    Cc: [email protected]
    Signed-off-by: Manish Pandey <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
selftests/bpf: Add a cgroup prog bpf_get_ns_current_pid_tgid() test [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Fri Mar 15 11:49:10 2024 -0700

    selftests/bpf: Add a cgroup prog bpf_get_ns_current_pid_tgid() test
    
    [ Upstream commit 87ade6cd859ea9dbde6e80b3fcf717ed9a73b4a9 ]
    
    Add a cgroup bpf program test where the bpf program is running
    in a pid namespace. The test is successfully:
      #165/3   ns_current_pid_tgid/new_ns_cgrp:OK
    
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 21f0b0af9772 ("selftests/bpf: Fix include of <sys/fcntl.h>")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Add CFLAGS per source file and runner [+ + +]
Author: Cupertino Miranda <[email protected]>
Date:   Tue May 7 13:22:19 2024 +0100

    selftests/bpf: Add CFLAGS per source file and runner
    
    [ Upstream commit 207cf6e649ee551ab3bdb1cfe1b2848e6a4337a5 ]
    
    This patch adds support to specify CFLAGS per source file and per test
    runner.
    
    Signed-off-by: Cupertino Miranda <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Yonghong Song <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 3ece93a4087b ("selftests/bpf: Fix wrong binary in Makefile log output")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Drop unneeded error.h includes [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:31 2024 -0700

    selftests/bpf: Drop unneeded error.h includes
    
    [ Upstream commit 69f409469c9b1515a5db40d5a36fda372376fa2d ]
    
    The addition of general support for unprivileged tests in test_loader.c
    breaks building test_verifier on non-glibc (e.g. musl) systems, due to the
    inclusion of glibc extension '<error.h>' in 'unpriv_helpers.c'. However,
    the header is actually not needed, so remove it to restore building.
    
    Similarly for sk_lookup.c and flow_dissector.c, error.h is not necessary
    and causes problems, so drop them.
    
    Fixes: 1d56ade032a4 ("selftests/bpf: Unprivileged tests for test_loader.c")
    Fixes: 0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point")
    Fixes: 0905beec9f52 ("selftests/bpf: run flow dissector tests in skb-less mode")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/5664367edf5fea4f3f4b4aec3b182bcfc6edff9c.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix arg parsing in veristat, test_progs [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:18 2024 -0700

    selftests/bpf: Fix arg parsing in veristat, test_progs
    
    [ Upstream commit 03bfcda1fbc37ef34aa21d2b9e09138335afc6ee ]
    
    Current code parses arguments with strtok_r() using a construct like
    
        char *state = NULL;
        while ((next = strtok_r(state ? NULL : input, ",", &state))) {
            ...
        }
    
    where logic assumes the 'state' var can distinguish between first and
    subsequent strtok_r() calls, and adjusts parameters accordingly. However,
    'state' is strictly internal context for strtok_r() and no such assumptions
    are supported in the man page. Moreover, the exact behaviour of 'state'
    depends on the libc implementation, making the above code fragile.
    
    Indeed, invoking "./test_progs -t <test_name>" on mips64el/musl will hang,
    with the above code in an infinite loop.
    
    Similarly, we see strange behaviour running 'veristat' on mips64el/musl:
    
        $ ./veristat -e file,prog,verdict,insns -C two-ok add-failure
        Can't specify more than 9 stats
    
    Rewrite code using a counter to distinguish between strtok_r() calls.
    
    Fixes: 61ddff373ffa ("selftests/bpf: Improve by-name subtest selection logic in prog_tests")
    Fixes: 394169b079b5 ("selftests/bpf: add comparison mode to veristat")
    Fixes: c8bc5e050976 ("selftests/bpf: Add veristat tool for mass-verifying BPF object files")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/392d8bf5559f85fa37926c1494e62312ef252c3d.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix C++ compile error from missing _Bool type [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:20 2024 -0700

    selftests/bpf: Fix C++ compile error from missing _Bool type
    
    [ Upstream commit aa95073fd290b5b3e45f067fa22bb25e59e1ff7c ]
    
    While building, bpftool makes a skeleton from test_core_extern.c, which
    itself includes <stdbool.h> and uses the 'bool' type. However, the skeleton
    test_core_extern.skel.h generated *does not* include <stdbool.h> or use the
    'bool' type, instead using the C-only '_Bool' type. Compiling test_cpp.cpp
    with g++ 12.3 for mips64el/musl-libc then fails with error:
    
      In file included from test_cpp.cpp:9:
      test_core_extern.skel.h:45:17: error: '_Bool' does not name a type
         45 |                 _Bool CONFIG_BOOL;
            |                 ^~~~~
    
    This was likely missed previously because glibc uses a GNU extension for
    <stdbool.h> with C++ (#define _Bool bool), not supported by musl libc.
    
    Normally, a C fragment would include <stdbool.h> and use the 'bool' type,
    and thus cleanly work after import by C++. The ideal fix would be for
    'bpftool gen skeleton' to output the correct type/include supporting C++,
    but in the meantime add a conditional define as above.
    
    Fixes: 7c8dce4b1661 ("bpftool: Make skeleton C code compilable with C++ compiler")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/6fc1dd28b8bda49e51e4f610bdc9d22f4455632d.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:29 2024 -0700

    selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c
    
    [ Upstream commit d393f9479d4aaab0fa4c3caf513f28685e831f13 ]
    
    Cast 'rlim_t' argument to match expected type of printf() format and avoid
    compile errors seen building for mips64el/musl-libc:
    
      In file included from map_tests/sk_storage_map.c:20:
      map_tests/sk_storage_map.c: In function 'test_sk_storage_map_stress_free':
      map_tests/sk_storage_map.c:414:56: error: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'rlim_t' {aka 'long long unsigned int'} [-Werror=format=]
        414 |                 CHECK(err, "setrlimit(RLIMIT_NOFILE)", "rlim_new:%lu errno:%d",
            |                                                        ^~~~~~~~~~~~~~~~~~~~~~~
        415 |                       rlim_new.rlim_cur, errno);
            |                       ~~~~~~~~~~~~~~~~~
            |                               |
            |                               rlim_t {aka long long unsigned int}
      ./test_maps.h:12:24: note: in definition of macro 'CHECK'
         12 |                 printf(format);                                         \
            |                        ^~~~~~
      map_tests/sk_storage_map.c:414:68: note: format string is defined here
        414 |                 CHECK(err, "setrlimit(RLIMIT_NOFILE)", "rlim_new:%lu errno:%d",
            |                                                                  ~~^
            |                                                                    |
            |                                                                    long unsigned int
            |                                                                  %llu
      cc1: all warnings being treated as errors
    
    Fixes: 51a0e301a563 ("bpf: Add BPF_MAP_TYPE_SK_STORAGE test to test_maps")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/1e00a1fa7acf91b4ca135c4102dc796d518bad86.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compile if backtrace support missing in libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:22 2024 -0700

    selftests/bpf: Fix compile if backtrace support missing in libc
    
    [ Upstream commit c9a83e76b5a96801a2c7ea0a79ca77c356d8b38d ]
    
    Include GNU <execinfo.h> header only with glibc and provide weak, stubbed
    backtrace functions as a fallback in test_progs.c. This allows for non-GNU
    replacements while avoiding compile errors (e.g. with musl libc) like:
    
      test_progs.c:13:10: fatal error: execinfo.h: No such file or directory
         13 | #include <execinfo.h> /* backtrace */
            |          ^~~~~~~~~~~~
      test_progs.c: In function 'crash_handler':
      test_progs.c:1034:14: error: implicit declaration of function 'backtrace' [-Werror=implicit-function-declaration]
       1034 |         sz = backtrace(bt, ARRAY_SIZE(bt));
            |              ^~~~~~~~~
      test_progs.c:1045:9: error: implicit declaration of function 'backtrace_symbols_fd' [-Werror=implicit-function-declaration]
       1045 |         backtrace_symbols_fd(bt, sz, STDERR_FILENO);
            |         ^~~~~~~~~~~~~~~~~~~~
    
    Fixes: 9fb156bb82a3 ("selftests/bpf: Print backtrace on SIGSEGV in test_progs")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/aa6dc8e23710cb457b278039d0081de7e7b4847d.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling core_reloc.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:42 2024 -0700

    selftests/bpf: Fix compiling core_reloc.c with musl-libc
    
    [ Upstream commit debfa4f628f271f72933bf38d581cc53cfe1def5 ]
    
    The type 'loff_t' is a GNU extension and not exposed by the musl 'fcntl.h'
    header unless _GNU_SOURCE is defined. Add this definition to fix errors
    seen compiling for mips64el/musl-libc:
    
      In file included from tools/testing/selftests/bpf/prog_tests/core_reloc.c:4:
      ./bpf_testmod/bpf_testmod.h:10:9: error: unknown type name 'loff_t'
         10 |         loff_t off;
            |         ^~~~~~
      ./bpf_testmod/bpf_testmod.h:16:9: error: unknown type name 'loff_t'
         16 |         loff_t off;
            |         ^~~~~~
    
    Fixes: 6bcd39d366b6 ("selftests/bpf: Add CO-RE relocs selftest relying on kernel module BTF")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/11c3af75a7eb6bcb7ad9acfae6a6f470c572eb82.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling flow_dissector.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:40 2024 -0700

    selftests/bpf: Fix compiling flow_dissector.c with musl-libc
    
    [ Upstream commit 5e4c43bcb85973243d7274e0058b6e8f5810e4f7 ]
    
    The GNU version of 'struct tcphdr' has members 'doff', 'source' and 'dest',
    which are not exposed by musl libc headers unless _GNU_SOURCE is defined.
    
    Add this definition to fix errors seen compiling for mips64el/musl-libc:
    
      flow_dissector.c:118:30: error: 'struct tcphdr' has no member named 'doff'
        118 |                         .tcp.doff = 5,
            |                              ^~~~
      flow_dissector.c:119:30: error: 'struct tcphdr' has no member named 'source'
        119 |                         .tcp.source = 80,
            |                              ^~~~~~
      flow_dissector.c:120:30: error: 'struct tcphdr' has no member named 'dest'
        120 |                         .tcp.dest = 8080,
            |                              ^~~~
    
    Fixes: ae173a915785 ("selftests/bpf: support BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/8f7ab21a73f678f9cebd32b26c444a686e57414d.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling kfree_skb.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:39 2024 -0700

    selftests/bpf: Fix compiling kfree_skb.c with musl-libc
    
    [ Upstream commit bae9a5ce7d3a9b3a9e07b31ab9e9c58450e3e9fd ]
    
    The GNU version of 'struct tcphdr' with member 'doff' is not exposed by
    musl headers unless _GNU_SOURCE is defined. Add this definition to fix
    errors seen compiling for mips64el/musl-libc:
    
      In file included from kfree_skb.c:2:
      kfree_skb.c: In function 'on_sample':
      kfree_skb.c:45:30: error: 'struct tcphdr' has no member named 'doff'
         45 |         if (CHECK(pkt_v6->tcp.doff != 5, "check_tcp",
            |                              ^
    
    Fixes: 580d656d80cf ("selftests/bpf: Add kfree_skb raw_tp test")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/e2d8cedc790959c10d6822a51f01a7a3616bea1b.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:38 2024 -0700

    selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc
    
    [ Upstream commit 4c329b99ef9c118343379bde9f97e8ce5cac9fc9 ]
    
    The GNU version of 'struct tcphdr', with members 'doff' and 'urg_ptr', is
    not exposed by musl headers unless _GNU_SOURCE is defined.
    
    Add this definition to fix errors seen compiling for mips64el/musl-libc:
    
      parse_tcp_hdr_opt.c:18:21: error: 'struct tcphdr' has no member named 'urg_ptr'
         18 |         .pk6_v6.tcp.urg_ptr = 123,
            |                     ^~~~~~~
      parse_tcp_hdr_opt.c:19:21: error: 'struct tcphdr' has no member named 'doff'
         19 |         .pk6_v6.tcp.doff = 9, /* 16 bytes of options */
            |                     ^~~~
    
    Fixes: cfa7b011894d ("selftests/bpf: tests for using dynptrs to parse skb and xdp buffers")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/ac5440213c242c62cb4e0d9e0a9cd5058b6a31f6.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix compiling tcp_rtt.c with musl-libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:41 2024 -0700

    selftests/bpf: Fix compiling tcp_rtt.c with musl-libc
    
    [ Upstream commit 18826fb0b79c3c3cd1fe765d85f9c6f1a902c722 ]
    
    The GNU version of 'struct tcp_info' in 'netinet/tcp.h' is not exposed by
    musl headers unless _GNU_SOURCE is defined.
    
    Add this definition to fix errors seen compiling for mips64el/musl-libc:
    
      tcp_rtt.c: In function 'wait_for_ack':
      tcp_rtt.c:24:25: error: storage size of 'info' isn't known
         24 |         struct tcp_info info;
            |                         ^~~~
      tcp_rtt.c:24:25: error: unused variable 'info' [-Werror=unused-variable]
      cc1: all warnings being treated as errors
    
    Fixes: 1f4f80fed217 ("selftests/bpf: test_progs: convert test_tcp_rtt")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/f2329767b15df206f08a5776d35a47c37da855ae.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:30 2024 -0700

    selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc
    
    [ Upstream commit 7b10f0c227ce3fa055d601f058dc411092a62a78 ]
    
    Existing code calls getsockname() with a 'struct sockaddr_in6 *' argument
    where a 'struct sockaddr *' argument is declared, yielding compile errors
    when building for mips64el/musl-libc:
    
      bpf_iter_setsockopt.c: In function 'get_local_port':
      bpf_iter_setsockopt.c:98:30: error: passing argument 2 of 'getsockname' from incompatible pointer type [-Werror=incompatible-pointer-types]
         98 |         if (!getsockname(fd, &addr, &addrlen))
            |                              ^~~~~
            |                              |
            |                              struct sockaddr_in6 *
      In file included from .../netinet/in.h:10,
                       from .../arpa/inet.h:9,
                       from ./test_progs.h:17,
                       from bpf_iter_setsockopt.c:5:
      .../sys/socket.h:391:23: note: expected 'struct sockaddr * restrict' but argument is of type 'struct sockaddr_in6 *'
        391 | int getsockname (int, struct sockaddr *__restrict, socklen_t *__restrict);
            |                       ^
      cc1: all warnings being treated as errors
    
    This compiled under glibc only because the argument is declared to be a
    "funky" transparent union which includes both types above. Explicitly cast
    the argument to allow compiling for both musl and glibc.
    
    Fixes: eed92afdd14c ("bpf: selftest: Test batching and bpf_(get|set)sockopt in bpf tcp iter")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Geliang Tang <[email protected]>
    Link: https://lore.kernel.org/bpf/f41def0f17b27a23b1709080e4e3f37f4cc11ca9.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix error compiling tc_redirect.c with musl libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:24 2024 -0700

    selftests/bpf: Fix error compiling tc_redirect.c with musl libc
    
    [ Upstream commit 21c5f4f55da759c7444a1ef13e90b6e6f674eeeb ]
    
    Linux 5.1 implemented 64-bit time types and related syscalls to address the
    Y2038 problem generally across archs. Userspace handling of Y2038 varies
    with the libc however. While musl libc uses 64-bit time across all 32-bit
    and 64-bit platforms, GNU glibc uses 64-bit time on 64-bit platforms but
    defaults to 32-bit time on 32-bit platforms unless they "opt-in" to 64-bit
    time or explicitly use 64-bit syscalls and time structures.
    
    One specific area is the standard setsockopt() call, SO_TIMESTAMPNS option
    used for timestamping, and the related output 'struct timespec'. GNU glibc
    defaults as above, also exposing the SO_TIMESTAMPNS_NEW flag to explicitly
    use a 64-bit call and 'struct __kernel_timespec'. Since these are not
    exposed or needed with musl libc, their use in tc_redirect.c leads to
    compile errors building for mips64el/musl:
    
      tc_redirect.c: In function 'rcv_tstamp':
      tc_redirect.c:425:32: error: 'SO_TIMESTAMPNS_NEW' undeclared (first use in this function); did you mean 'SO_TIMESTAMPNS'?
        425 |             cmsg->cmsg_type == SO_TIMESTAMPNS_NEW)
            |                                ^~~~~~~~~~~~~~~~~~
            |                                SO_TIMESTAMPNS
      tc_redirect.c:425:32: note: each undeclared identifier is reported only once for each function it appears in
      tc_redirect.c: In function 'test_inet_dtime':
      tc_redirect.c:491:49: error: 'SO_TIMESTAMPNS_NEW' undeclared (first use in this function); did you mean 'SO_TIMESTAMPNS'?
        491 |         err = setsockopt(listen_fd, SOL_SOCKET, SO_TIMESTAMPNS_NEW,
            |                                                 ^~~~~~~~~~~~~~~~~~
            |                                                 SO_TIMESTAMPNS
    
    However, using SO_TIMESTAMPNS_NEW isn't strictly needed, nor is Y2038 being
    explicitly tested. The timestamp checks in tc_redirect.c are simple: the
    packet receive timestamp is non-zero and processed/handled in less than 5
    seconds.
    
    Switch to using the standard setsockopt() call and SO_TIMESTAMPNS option to
    ensure compatibility across glibc and musl libc. In the worst-case, there
    is a 5-second window 14 years from now where tc_redirect tests may fail on
    32-bit systems. However, we should reasonably expect glibc to adopt a
    64-bit mandate rather than the current "opt-in" policy before the Y2038
    roll-over.
    
    Fixes: ce6f6cffaeaa ("selftests/bpf: Wait for the netstamp_needed_key static key to be turned on")
    Fixes: c803475fd8dd ("bpf: selftests: test skb->tstamp in redirect_neigh")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/031d656c058b4e55ceae56ef49c4e1729b5090f3.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix error compiling test_lru_map.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:19 2024 -0700

    selftests/bpf: Fix error compiling test_lru_map.c
    
    [ Upstream commit cacf2a5a78cd1f5f616eae043ebc6f024104b721 ]
    
    Although the post-increment in macro 'CPU_SET(next++, &cpuset)' seems safe,
    the sequencing can raise compile errors, so move the increment outside the
    macro. This avoids an error seen using gcc 12.3.0 for mips64el/musl-libc:
    
      In file included from test_lru_map.c:11:
      test_lru_map.c: In function 'sched_next_online':
      test_lru_map.c:129:29: error: operation on 'next' may be undefined [-Werror=sequence-point]
        129 |                 CPU_SET(next++, &cpuset);
            |                             ^
      cc1: all warnings being treated as errors
    
    Fixes: 3fbfadce6012 ("bpf: Fix test_lru_sanity5() in test_lru_map.c")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/22993dfb11ccf27925a626b32672fd3324cb76c4.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix error linking uprobe_multi on mips [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 17:13:29 2024 -0700

    selftests/bpf: Fix error linking uprobe_multi on mips
    
    [ Upstream commit a5f40d596bff182b4b47547712f540885e8fb17b ]
    
    Linking uprobe_multi.c on mips64el fails due to relocation overflows, when
    the GOT entries required exceeds the default maximum. Add a specific CFLAGS
    (-mxgot) for uprobe_multi.c on MIPS that allows using a larger GOT and
    avoids errors such as:
    
      /tmp/ccBTNQzv.o: in function `bench':
      uprobe_multi.c:49:(.text+0x1d7720): relocation truncated to fit: R_MIPS_GOT_DISP against `uprobe_multi_func_08188'
      uprobe_multi.c:49:(.text+0x1d7730): relocation truncated to fit: R_MIPS_GOT_DISP against `uprobe_multi_func_08189'
      ...
      collect2: error: ld returned 1 exit status
    
    Fixes: 519dfeaf5119 ("selftests/bpf: Add uprobe_multi test program")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/14eb7b70f8ccef9834874d75eb373cb9292129da.1721692479.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:46 2024 -0700

    selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc
    
    [ Upstream commit 730561d3c08d4a327cceaabf11365958a1c00cec ]
    
    Remove a redundant include of '<asm/types.h>', whose needed definitions are
    already included (via '<linux/types.h>') in cg_storage_multi_egress_only.c,
    cg_storage_multi_isolated.c, and cg_storage_multi_shared.c. This avoids
    redefinition errors seen compiling for mips64el/musl-libc like:
    
      In file included from progs/cg_storage_multi_egress_only.c:13:
      In file included from progs/cg_storage_multi.h:6:
      In file included from /usr/mips64el-linux-gnuabi64/include/asm/types.h:23:
      /usr/include/asm-generic/int-l64.h:29:25: error: typedef redefinition with different types ('long' vs 'long long')
         29 | typedef __signed__ long __s64;
            |                         ^
      /usr/include/asm-generic/int-ll64.h:30:44: note: previous definition is here
         30 | __extension__ typedef __signed__ long long __s64;
            |                                            ^
    
    Fixes: 9e5bd1f7633b ("selftests/bpf: Test CGROUP_STORAGE map can't be used by multiple progs")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/4f4702e9f6115b7f84fea01b2326ca24c6df7ba8.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix errors compiling decap_sanity.c with musl libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:44 2024 -0700

    selftests/bpf: Fix errors compiling decap_sanity.c with musl libc
    
    [ Upstream commit 1b00f355130a5dfc38a01ad02458ae2cb2ebe609 ]
    
    Remove a redundant include of '<linux/in6.h>', whose needed definitions are
    already provided by 'test_progs.h'. This avoids errors seen compiling for
    mips64el/musl-libc:
    
      In file included from .../arpa/inet.h:9,
                       from ./test_progs.h:17,
                       from prog_tests/decap_sanity.c:9:
      .../netinet/in.h:23:8: error: redefinition of 'struct in6_addr'
         23 | struct in6_addr {
            |        ^~~~~~~~
      In file included from decap_sanity.c:7:
      .../linux/in6.h:33:8: note: originally defined here
         33 | struct in6_addr {
            |        ^~~~~~~~
      .../netinet/in.h:34:8: error: redefinition of 'struct sockaddr_in6'
         34 | struct sockaddr_in6 {
            |        ^~~~~~~~~~~~
      .../linux/in6.h:50:8: note: originally defined here
         50 | struct sockaddr_in6 {
            |        ^~~~~~~~~~~~
      .../netinet/in.h:42:8: error: redefinition of 'struct ipv6_mreq'
         42 | struct ipv6_mreq {
            |        ^~~~~~~~~
      .../linux/in6.h:60:8: note: originally defined here
         60 | struct ipv6_mreq {
            |        ^~~~~~~~~
    
    Fixes: 70a00e2f1dba ("selftests/bpf: Test bpf_skb_adjust_room on CHECKSUM_PARTIAL")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/e986ba2d7edccd254b54f7cd049b98f10bafa8c3.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:43 2024 -0700

    selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc
    
    [ Upstream commit 27c4797ce51c8dd51e35e68e9024a892f62d78b2 ]
    
    Remove a redundant include of '<linux/icmp.h>' which is already provided in
    'lwt_helpers.h'. This avoids errors seen compiling for mips64el/musl-libc:
    
      In file included from .../arpa/inet.h:9,
                       from lwt_redirect.c:51:
      .../netinet/in.h:23:8: error: redefinition of 'struct in6_addr'
         23 | struct in6_addr {
            |        ^~~~~~~~
      In file included from .../linux/icmp.h:24,
                       from lwt_redirect.c:50:
      .../linux/in6.h:33:8: note: originally defined here
         33 | struct in6_addr {
            |        ^~~~~~~~
      .../netinet/in.h:34:8: error: redefinition of 'struct sockaddr_in6'
         34 | struct sockaddr_in6 {
            |        ^~~~~~~~~~~~
      .../linux/in6.h:50:8: note: originally defined here
         50 | struct sockaddr_in6 {
            |        ^~~~~~~~~~~~
      .../netinet/in.h:42:8: error: redefinition of 'struct ipv6_mreq'
         42 | struct ipv6_mreq {
            |        ^~~~~~~~~
      .../linux/in6.h:60:8: note: originally defined here
         60 | struct ipv6_mreq {
            |        ^~~~~~~~~
    
    Fixes: 43a7c3ef8a15 ("selftests/bpf: Add lwt_xmit tests for BPF_REDIRECT")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/3869dda876d5206d2f8d4dd67331c739ceb0c7f8.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix flaky selftest lwt_redirect/lwt_reroute [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Sun Feb 4 21:29:14 2024 -0800

    selftests/bpf: Fix flaky selftest lwt_redirect/lwt_reroute
    
    [ Upstream commit e7f31873176a345d72ca77c7b4da48493ccd9efd ]
    
    Recently, when running './test_progs -j', I occasionally hit the
    following errors:
    
      test_lwt_redirect:PASS:pthread_create 0 nsec
      test_lwt_redirect_run:FAIL:netns_create unexpected error: 256 (errno 0)
      #142/2   lwt_redirect/lwt_redirect_normal_nomac:FAIL
      #142     lwt_redirect:FAIL
      test_lwt_reroute:PASS:pthread_create 0 nsec
      test_lwt_reroute_run:FAIL:netns_create unexpected error: 256 (errno 0)
      test_lwt_reroute:PASS:pthread_join 0 nsec
      #143/2   lwt_reroute/lwt_reroute_qdisc_dropped:FAIL
      #143     lwt_reroute:FAIL
    
    The netns_create() definition looks like below:
    
      #define NETNS "ns_lwt"
      static inline int netns_create(void)
      {
            return system("ip netns add " NETNS);
      }
    
    One possibility is that both lwt_redirect and lwt_reroute create
    netns with the same name "ns_lwt" which may cause conflict. I tried
    the following example:
      $ sudo ip netns add abc
      $ echo $?
      0
      $ sudo ip netns add abc
      Cannot create namespace file "/var/run/netns/abc": File exists
      $ echo $?
      1
      $
    
    The return code for above netns_create() is 256. The internet search
    suggests that the return value for 'ip netns add ns_lwt' is 1, which
    matches the above 'sudo ip netns add abc' example.
    
    This patch tried to use different netns names for two tests to avoid
    'ip netns add <name>' failure.
    
    I ran './test_progs -j' 10 times and all succeeded with
    lwt_redirect/lwt_reroute tests.
    
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Tested-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 16b795cc5952 ("selftests/bpf: Fix redefinition errors compiling lwt_reroute.c")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix include of [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:37 2024 -0700

    selftests/bpf: Fix include of <sys/fcntl.h>
    
    [ Upstream commit 21f0b0af977203220ad58aff95e372151288ec47 ]
    
    Update ns_current_pid_tgid.c to use '#include <fcntl.h>' and avoid compile
    error against mips64el/musl libc:
    
      In file included from .../prog_tests/ns_current_pid_tgid.c:14:
      .../include/sys/fcntl.h:1:2: error: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h> [-Werror=cpp]
          1 | #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h>
            |  ^~~~~~~
      cc1: all warnings being treated as errors
    
    Fixes: 09c02d553c49 ("bpf, selftests: Fold test_current_pid_tgid_new_ns into test_progs.")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/8bdc869749177b575025bf69600a4ce591822609.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:34 2024 -0700

    selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c
    
    [ Upstream commit d44c93fc2f5a0c47b23fa03d374e45259abd92d2 ]
    
    Add a "bpf_util.h" include to avoid the following error seen compiling for
    mips64el with musl libc:
    
      bench.c: In function 'find_benchmark':
      bench.c:590:25: error: implicit declaration of function 'ARRAY_SIZE' [-Werror=implicit-function-declaration]
        590 |         for (i = 0; i < ARRAY_SIZE(benchs); i++) {
            |                         ^~~~~~~~~~
      cc1: all warnings being treated as errors
    
    Fixes: 8e7c2a023ac0 ("selftests/bpf: Add benchmark runner infrastructure")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/bc4dde77dfcd17a825d8f28f72f3292341966810.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix missing BUILD_BUG_ON() declaration [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:36 2024 -0700

    selftests/bpf: Fix missing BUILD_BUG_ON() declaration
    
    [ Upstream commit 6495eb79ca7d15bd87c38d77307e8f9b6b7bf4ef ]
    
    Explicitly include '<linux/build_bug.h>' to fix errors seen compiling with
    gcc targeting mips64el/musl-libc:
    
      user_ringbuf.c: In function 'test_user_ringbuf_loop':
      user_ringbuf.c:426:9: error: implicit declaration of function 'BUILD_BUG_ON' [-Werror=implicit-function-declaration]
        426 |         BUILD_BUG_ON(total_samples <= c_max_entries);
            |         ^~~~~~~~~~~~
      cc1: all warnings being treated as errors
    
    Fixes: e5a9df51c746 ("selftests/bpf: Add selftests validating the user ringbuf")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/b28575f9221ec54871c46a2e87612bb4bbf46ccd.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix missing UINT_MAX definitions in benchmarks [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:35 2024 -0700

    selftests/bpf: Fix missing UINT_MAX definitions in benchmarks
    
    [ Upstream commit a2c155131b710959beb508ca6a54769b6b1bd488 ]
    
    Include <limits.h> in 'bench.h' to provide a UINT_MAX definition and avoid
    multiple compile errors against mips64el/musl-libc like:
    
      benchs/bench_local_storage.c: In function 'parse_arg':
      benchs/bench_local_storage.c:40:38: error: 'UINT_MAX' undeclared (first use in this function)
         40 |                 if (ret < 1 || ret > UINT_MAX) {
            |                                      ^~~~~~~~
      benchs/bench_local_storage.c:11:1: note: 'UINT_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
         10 | #include <test_btf.h>
        +++ |+#include <limits.h>
         11 |
    
    seen with bench_local_storage.c, bench_local_storage_rcu_tasks_trace.c, and
    bench_bpf_hashmap_lookup.c.
    
    Fixes: 73087489250d ("selftests/bpf: Add benchmark for local_storage get")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/8f64a9d9fcff40a7fca090a65a68a9b62a468e16.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix redefinition errors compiling lwt_reroute.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 29 02:24:21 2024 -0700

    selftests/bpf: Fix redefinition errors compiling lwt_reroute.c
    
    [ Upstream commit 16b795cc59528cf280abc79af3c70bda42f715b9 ]
    
    Compiling lwt_reroute.c with GCC 12.3 for mips64el/musl-libc yields errors:
    
    In file included from .../include/arpa/inet.h:9,
                     from ./test_progs.h:18,
                     from tools/testing/selftests/bpf/prog_tests/lwt_helpers.h:11,
                     from tools/testing/selftests/bpf/prog_tests/lwt_reroute.c:52:
    .../include/netinet/in.h:23:8: error: redefinition of 'struct in6_addr'
       23 | struct in6_addr {
          |        ^~~~~~~~
    In file included from .../include/linux/icmp.h:24,
                     from tools/testing/selftests/bpf/prog_tests/lwt_helpers.h:9:
    .../include/linux/in6.h:33:8: note: originally defined here
       33 | struct in6_addr {
          |        ^~~~~~~~
    .../include/netinet/in.h:34:8: error: redefinition of 'struct sockaddr_in6'
       34 | struct sockaddr_in6 {
          |        ^~~~~~~~~~~~
    .../include/linux/in6.h:50:8: note: originally defined here
       50 | struct sockaddr_in6 {
          |        ^~~~~~~~~~~~
    .../include/netinet/in.h:42:8: error: redefinition of 'struct ipv6_mreq'
       42 | struct ipv6_mreq {
          |        ^~~~~~~~~
    .../include/linux/in6.h:60:8: note: originally defined here
       60 | struct ipv6_mreq {
          |        ^~~~~~~~~
    
    These errors occur because <linux/in6.h> is included before <netinet/in.h>,
    bypassing the Linux uapi/libc compat mechanism's partial musl support. As
    described in [1] and [2], fix these errors by including <netinet/in.h> in
    lwt_reroute.c before any uapi headers.
    
    [1]: commit c0bace798436 ("uapi libc compat: add fallback for unsupported libcs")
    [2]: https://git.musl-libc.org/cgit/musl/commit/?id=04983f227238
    
    Fixes: 6c77997bc639 ("selftests/bpf: Add lwt_xmit tests for BPF_REROUTE")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/bd2908aec0755ba8b75f5dc41848b00585f5c73e.1722244708.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Fix wrong binary in Makefile log output [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Fri Jul 19 22:25:35 2024 -0700

    selftests/bpf: Fix wrong binary in Makefile log output
    
    [ Upstream commit 3ece93a4087b2db7b99ebb2412bd60cf26bbbb51 ]
    
    Make log output incorrectly shows 'test_maps' as the binary name for every
    'CLNG-BPF' build step, apparently picking up the last value defined for the
    $(TRUNNER_BINARY) variable. Update the 'CLANG_BPF_BUILD_RULE' variants to
    fix this confusing output.
    
    Current output:
      CLNG-BPF [test_maps] access_map_in_map.bpf.o
      GEN-SKEL [test_progs] access_map_in_map.skel.h
      ...
      CLNG-BPF [test_maps] access_map_in_map.bpf.o
      GEN-SKEL [test_progs-no_alu32] access_map_in_map.skel.h
      ...
      CLNG-BPF [test_maps] access_map_in_map.bpf.o
      GEN-SKEL [test_progs-cpuv4] access_map_in_map.skel.h
    
    After fix:
      CLNG-BPF [test_progs] access_map_in_map.bpf.o
      GEN-SKEL [test_progs] access_map_in_map.skel.h
      ...
      CLNG-BPF [test_progs-no_alu32] access_map_in_map.bpf.o
      GEN-SKEL [test_progs-no_alu32] access_map_in_map.skel.h
      ...
      CLNG-BPF [test_progs-cpuv4] access_map_in_map.bpf.o
      GEN-SKEL [test_progs-cpuv4] access_map_in_map.skel.h
    
    Fixes: a5d0c26a2784 ("selftests/bpf: Add a cpuv4 test runner for cpu=v4 testing")
    Fixes: 89ad7420b25c ("selftests/bpf: Drop the need for LLVM's llc")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Eduard Zingerman <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Implement get_hw_ring_size function to retrieve current and max interface size [+ + +]
Author: Tushar Vyavahare <[email protected]>
Date:   Tue Apr 2 11:45:25 2024 +0000

    selftests/bpf: Implement get_hw_ring_size function to retrieve current and max interface size
    
    [ Upstream commit 90a695c3d31e1c9f0adb8c4c80028ed4ea7ed5ab ]
    
    Introduce a new function called get_hw_size that retrieves both the
    current and maximum size of the interface and stores this information
    in the 'ethtool_ringparam' structure.
    
    Remove ethtool_channels struct from xdp_hw_metadata.c due to redefinition
    error. Remove unused linux/if.h include from flow_dissector BPF test to
    address CI pipeline failure.
    
    Signed-off-by: Tushar Vyavahare <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Magnus Karlsson <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 69f409469c9b ("selftests/bpf: Drop unneeded error.h includes")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Refactor out some functions in ns_current_pid_tgid test [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Fri Mar 15 11:49:04 2024 -0700

    selftests/bpf: Refactor out some functions in ns_current_pid_tgid test
    
    [ Upstream commit 4d4bd29e363c467752536f874a2cba10a5923c59 ]
    
    Refactor some functions in both user space code and bpf program
    as these functions are used by later cgroup/sk_msg tests.
    Another change is to mark tp program optional loading as later
    patches will use optional loading as well since they have quite
    different attachment and testing logic.
    
    There is no functionality change.
    
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 21f0b0af9772 ("selftests/bpf: Fix include of <sys/fcntl.h>")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Replace CHECK with ASSERT_* in ns_current_pid_tgid test [+ + +]
Author: Yonghong Song <[email protected]>
Date:   Fri Mar 15 11:48:59 2024 -0700

    selftests/bpf: Replace CHECK with ASSERT_* in ns_current_pid_tgid test
    
    [ Upstream commit 84239a24d10174fcfc7d6760cb120435a6ff69af ]
    
    Replace CHECK in selftest ns_current_pid_tgid with recommended ASSERT_* style.
    I also shortened subtest name as the prefix of subtest name is covered
    by the test name already.
    
    This patch does fix a testing issue. Currently even if bss->user_{pid,tgid}
    is not correct, the test still passed since the clone func returns 0.
    I fixed it to return a non-zero value if bss->user_{pid,tgid} is incorrect.
    
    Signed-off-by: Yonghong Song <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Jiri Olsa <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Stable-dep-of: 21f0b0af9772 ("selftests/bpf: Fix include of <sys/fcntl.h>")
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Use pid_t consistently in test_progs.c [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 22:54:28 2024 -0700

    selftests/bpf: Use pid_t consistently in test_progs.c
    
    [ Upstream commit ec4fe2f0fa12fd2d0115df7e58414dc26899cc5e ]
    
    Use pid_t rather than __pid_t when allocating memory for 'worker_pids' in
    'struct test_env', as this is its declared type and also avoids compile
    errors seen building against musl libc on mipsel64:
    
      test_progs.c:1738:49: error: '__pid_t' undeclared (first use in this function); did you mean 'pid_t'?
       1738 |                 env.worker_pids = calloc(sizeof(__pid_t), env.workers);
            |                                                 ^~~~~~~
            |                                                 pid_t
      test_progs.c:1738:49: note: each undeclared identifier is reported only once for each function it appears in
    
    Fixes: 91b2c0afd00c ("selftests/bpf: Add parallelism to test_progs")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Geliang Tang <[email protected]>
    Link: https://lore.kernel.org/bpf/c6447da51a94babc1931711a43e2ceecb135c93d.1721713597.git.tony.ambardar@gmail.com
    Signed-off-by: Sasha Levin <[email protected]>

selftests/bpf: Workaround strict bpf_lsm return value check. [+ + +]
Author: Alexei Starovoitov <[email protected]>
Date:   Mon Jul 22 19:08:15 2024 -0700

    selftests/bpf: Workaround strict bpf_lsm return value check.
    
    [ Upstream commit aa8ebb270c66cea1f56a25d0f938036e91ad085a ]
    
    test_progs-no_alu32 -t libbpf_get_fd_by_id_opts
    is being rejected by the verifier with the following error
    due to compiler optimization:
    
    6: (67) r0 <<= 62                     ; R0_w=scalar(smax=0x4000000000000000,umax=0xc000000000000000,smin32=0,smax32=umax32=0,var_off=(0x0; 0xc000000000000000))
    7: (c7) r0 s>>= 63                    ; R0_w=scalar(smin=smin32=-1,smax=smax32=0)
    ;  @ test_libbpf_get_fd_by_id_opts.c:0
    8: (57) r0 &= -13                     ; R0_w=scalar(smax=0x7ffffffffffffff3,umax=0xfffffffffffffff3,smax32=0x7ffffff3,umax32=0xfffffff3,var_off=(0x0; 0xfffffffffffffff3))
    ; int BPF_PROG(check_access, struct bpf_map *map, fmode_t fmode) @ test_libbpf_get_fd_by_id_opts.c:27
    9: (95) exit
    At program exit the register R0 has smax=9223372036854775795 should have been in [-4095, 0]
    
    Workaround by adding barrier().
    Eventually the verifier will be able to recognize it.
    
    Fixes: 5d99e198be27 ("bpf, lsm: Add check for BPF LSM return value")
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
selftests/ftrace: Add required dependency for kprobe tests [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Thu Jun 13 07:12:10 2024 +0900

    selftests/ftrace: Add required dependency for kprobe tests
    
    [ Upstream commit 41f37c852ac3fbfd072a00281b60dc7ba056be8c ]
    
    kprobe_args_{char,string}.tc are using available_filter_functions file
    which is provided by function tracer. Thus if function tracer is disabled,
    these tests are failed on recent kernels because tracefs_create_dir is
    not raised events by adding a dynamic event.
    Add available_filter_functions to requires line.
    
    Fixes: 7c1130ea5cae ("test: ftrace: Fix kprobe test for eventfs")
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Signed-off-by: Shuah Khan <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250: omap: Cleanup on error in request_irq [+ + +]
Author: Markus Schneider-Pargmann <[email protected]>
Date:   Wed Aug 7 16:12:25 2024 +0200

    serial: 8250: omap: Cleanup on error in request_irq
    
    [ Upstream commit 35e648a16018b747897be2ccc3ce95ff23237bb5 ]
    
    If devm_request_irq fails, the code does not cleanup many things that
    were setup before. Instead of directly returning ret we should jump to
    err.
    
    Fixes: fef4f600319e ("serial: 8250: omap: Fix life cycle issues for interrupt handlers")
    Signed-off-by: Markus Schneider-Pargmann <[email protected]>
    Reviewed-by: Kevin Hilman <[email protected]>
    Tested-by: Kevin Hilman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: don't use uninitialized value in uart_poll_init() [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Mon Aug 5 12:20:36 2024 +0200

    serial: don't use uninitialized value in uart_poll_init()
    
    [ Upstream commit d0009a32c9e4e083358092f3c97e3c6e803a8930 ]
    
    Coverity reports (as CID 1536978) that uart_poll_init() passes
    uninitialized pm_state to uart_change_pm(). It is in case the first 'if'
    takes the true branch (does "goto out;").
    
    Fix this and simplify the function by simple guard(mutex). The code
    needs no labels after this at all. And it is pretty clear that the code
    has not fiddled with pm_state at that point.
    
    Signed-off-by: Jiri Slaby (SUSE) <[email protected]>
    Fixes: 5e227ef2aa38 (serial: uart_poll_init() should power on the UART)
    Cc: [email protected]
    Cc: Douglas Anderson <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Reviewed-by: Douglas Anderson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

serial: qcom-geni: fix fifo polling timeout [+ + +]
Author: Johan Hovold <[email protected]>
Date:   Fri Sep 6 15:13:29 2024 +0200

    serial: qcom-geni: fix fifo polling timeout
    
    commit c80ee36ac8f9e9c27d8e097a2eaaf198e7534c83 upstream.
    
    The qcom_geni_serial_poll_bit() can be used to wait for events like
    command completion and is supposed to wait for the time it takes to
    clear a full fifo before timing out.
    
    As noted by Doug, the current implementation does not account for start,
    stop and parity bits when determining the timeout. The helper also does
    not currently account for the shift register and the two-word
    intermediate transfer register.
    
    A too short timeout can specifically lead to lost characters when
    waiting for a transfer to complete as the transfer is cancelled on
    timeout.
    
    Instead of determining the poll timeout on every call, store the fifo
    timeout when updating it in set_termios() and make sure to take the
    shift and intermediate registers into account. Note that serial core has
    already added a 20 ms margin to the fifo timeout.
    
    Also note that the current uart_fifo_timeout() interface does
    unnecessary calculations on every call and did not exist in earlier
    kernels so only store its result once. This facilitates backports too as
    earlier kernels can derive the timeout from uport->timeout, which has
    since been removed.
    
    Fixes: c4f528795d1a ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP")
    Cc: [email protected]      # 4.17
    Reported-by: Douglas Anderson <[email protected]>
    Tested-by: Nícolas F. R. A. Prado <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso [+ + +]
Author: Jiawei Ye <[email protected]>
Date:   Mon Sep 2 08:47:26 2024 +0000

    smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso
    
    [ Upstream commit 2749749afa071f8a0e405605de9da615e771a7ce ]
    
    In the `smk_set_cipso` function, the `skp->smk_netlabel.attr.mls.cat`
    field is directly assigned to a new value without using the appropriate
    RCU pointer assignment functions. According to RCU usage rules, this is
    illegal and can lead to unpredictable behavior, including data
    inconsistencies and impossible-to-diagnose memory corruption issues.
    
    This possible bug was identified using a static analysis tool developed
    by myself, specifically designed to detect RCU-related issues.
    
    To address this, the assignment is now done using rcu_assign_pointer(),
    which ensures that the pointer assignment is done safely, with the
    necessary memory barriers and synchronization. This change prevents
    potential RCU dereference issues by ensuring that the `cat` field is
    safely updated while still adhering to RCU's requirements.
    
    Fixes: 0817534ff9ea ("smackfs: Fix use-after-free in netlbl_catmap_walk()")
    Signed-off-by: Jiawei Ye <[email protected]>
    Signed-off-by: Casey Schaufler <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
soc: fsl: cpm1: tsa: Fix tsa_write8() [+ + +]
Author: Herve Codina <[email protected]>
Date:   Thu Aug 8 09:10:56 2024 +0200

    soc: fsl: cpm1: tsa: Fix tsa_write8()
    
    commit 47a347bae9a491b467ab3543e4725a3e4fbe30f5 upstream.
    
    The tsa_write8() parameter is an u32 value. This is not consistent with
    the function itself. Indeed, tsa_write8() writes an 8bits value.
    
    Be consistent and use an u8 parameter value.
    
    Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
    Cc: [email protected]
    Signed-off-by: Herve Codina <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Christophe Leroy <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

soc: versatile: integrator: fix OF node leak in probe() error path [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:22 2024 +0200

    soc: versatile: integrator: fix OF node leak in probe() error path
    
    commit 874c5b601856adbfda10846b9770a6c66c41e229 upstream.
    
    Driver is leaking OF node reference obtained from
    of_find_matching_node().
    
    Fixes: f956a785a282 ("soc: move SoC driver for the ARM Integrator")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

soc: versatile: realview: fix memory leak during device remove [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:23 2024 +0200

    soc: versatile: realview: fix memory leak during device remove
    
    [ Upstream commit 1c4f26a41f9d052f334f6ae629e01f598ed93508 ]
    
    If device is unbound, the memory allocated for soc_dev_attr should be
    freed to prevent leaks.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Stable-dep-of: c774f2564c00 ("soc: versatile: realview: fix soc_dev leak during device remove")
    Signed-off-by: Sasha Levin <[email protected]>

soc: versatile: realview: fix soc_dev leak during device remove [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Aug 25 20:05:24 2024 +0200

    soc: versatile: realview: fix soc_dev leak during device remove
    
    [ Upstream commit c774f2564c0086c23f5269fd4691f233756bf075 ]
    
    If device is unbound, the soc_dev should be unregistered to prevent
    memory leak.
    
    Fixes: a2974c9c1f83 ("soc: add driver for the ARM RealView")
    Cc: [email protected]
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/[email protected]
    Signed-off-by: Linus Walleij <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
sock_map: Add a cond_resched() in sock_hash_free() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Sep 6 15:44:49 2024 +0000

    sock_map: Add a cond_resched() in sock_hash_free()
    
    [ Upstream commit b1339be951ad31947ae19bc25cb08769bf255100 ]
    
    Several syzbot soft lockup reports all have in common sock_hash_free()
    
    If a map with a large number of buckets is destroyed, we need to yield
    the cpu when needed.
    
    Fixes: 75e68e5bf2c7 ("bpf, sockhash: Synchronize delete from bucket list on map free")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Acked-by: Martin KaFai Lau <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: atmel-quadspi: Avoid overwriting delay register settings [+ + +]
Author: Alexander Dahl <[email protected]>
Date:   Wed Sep 18 10:27:43 2024 +0200

    spi: atmel-quadspi: Avoid overwriting delay register settings
    
    [ Upstream commit 329ca3eed4a9a161515a8714be6ba182321385c7 ]
    
    Previously the MR and SCR registers were just set with the supposedly
    required values, from cached register values (cached reg content
    initialized to zero).
    
    All parts fixed here did not consider the current register (cache)
    content, which would make future support of cs_setup, cs_hold, and
    cs_inactive impossible.
    
    Setting SCBR in atmel_qspi_setup() erases a possible DLYBS setting from
    atmel_qspi_set_cs_timing().  The DLYBS setting is applied by ORing over
    the current setting, without resetting the bits first.  All writes to MR
    did not consider possible settings of DLYCS and DLYBCT.
    
    Signed-off-by: Alexander Dahl <[email protected]>
    Fixes: f732646d0ccd ("spi: atmel-quadspi: Add support for configuring CS timing")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: atmel-quadspi: Fix wrong register value written to MR [+ + +]
Author: Alexander Dahl <[email protected]>
Date:   Thu Sep 26 11:03:56 2024 +0200

    spi: atmel-quadspi: Fix wrong register value written to MR
    
    commit 162d9b5d2308c7e48efbc97d36babbf4d73b2c61 upstream.
    
    aq->mr should go to MR, nothing else.
    
    Fixes: 329ca3eed4a9 ("spi: atmel-quadspi: Avoid overwriting delay register settings")
    Signed-off-by: Alexander Dahl <[email protected]>
    Link: https://lore.kernel.org/linux-spi/[email protected]/T/#u
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: atmel-quadspi: Undo runtime PM changes at driver exit time [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Fri Sep 6 10:39:56 2024 +0800

    spi: atmel-quadspi: Undo runtime PM changes at driver exit time
    
    [ Upstream commit 438efb23f9581659495b85f1f6c7d5946200660c ]
    
    It's important to undo pm_runtime_use_autosuspend() with
    pm_runtime_dont_use_autosuspend() at driver exit time unless driver
    initially enabled pm_runtime with devm_pm_runtime_enable()
    (which handles it for you).
    
    Hence, call pm_runtime_dont_use_autosuspend() at driver exit time
    to fix it.
    
    Fixes: 4a2f83b7f780 ("spi: atmel-quadspi: add runtime pm support")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: bcmbca-hsspi: Fix missing pm_runtime_disable() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Mon Aug 26 20:49:02 2024 +0800

    spi: bcmbca-hsspi: Fix missing pm_runtime_disable()
    
    [ Upstream commit 4439a2e92cb89028b22c5d7ba1b99e75d7d889f6 ]
    
    The pm_runtime_disable() is missing in remove function, use
    devm_pm_runtime_enable() to fix it. So the pm_runtime_disable() in
    the probe error path can also be removed.
    
    Fixes: a38a2233f23b ("spi: bcmbca-hsspi: Add driver for newer HSSPI controller")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Reviewed-by: William Zhang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: fspi: add support for imx8ulp [+ + +]
Author: Haibo Chen <[email protected]>
Date:   Thu Sep 5 17:43:37 2024 +0800

    spi: fspi: add support for imx8ulp
    
    commit 9228956a620553d7fd17f703a37a26c91e4d92ab upstream.
    
    The flexspi on imx8ulp only has 16 LUTs, different with others which
    have up to 32 LUTs.
    
    Add a separate compatible string and nxp_fspi_devtype_data to support
    flexspi on imx8ulp.
    
    Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node")
    Cc: [email protected]
    Signed-off-by: Haibo Chen <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: fspi: involve lut_num for struct nxp_fspi_devtype_data [+ + +]
Author: Haibo Chen <[email protected]>
Date:   Thu Sep 5 17:43:36 2024 +0800

    spi: fspi: involve lut_num for struct nxp_fspi_devtype_data
    
    commit 190b7e2efb1ed8435fc7431d9c7a2447d05d5066 upstream.
    
    The flexspi on different SoCs may have different number of LUTs.
    So involve lut_num in nxp_fspi_devtype_data to make distinguish.
    This patch prepare for the adding of imx8ulp.
    
    Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node")
    Cc: [email protected]
    Signed-off-by: Haibo Chen <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Wed Aug 14 17:45:12 2024 +0300

    spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ
    
    [ Upstream commit 7781f1d120fec8624fc654eda900fc8748262082 ]
    
    0 is incorrect error code when failed to parse and map IRQ.
    Replace OF specific old API for IRQ retrieval with a generic
    one to fix this issue.
    
    Fixes: 0f245463b01e ("spi: ppc4xx: handle irq_of_parse_and_map() errors")
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: ppc4xx: handle irq_of_parse_and_map() errors [+ + +]
Author: Ma Ke <[email protected]>
Date:   Wed Jul 24 16:40:47 2024 +0800

    spi: ppc4xx: handle irq_of_parse_and_map() errors
    
    [ Upstream commit 0f245463b01ea254ae90e1d0389e90b0e7d8dc75 ]
    
    Zero and negative number is not a valid IRQ for in-kernel code and the
    irq_of_parse_and_map() function returns zero on error.  So this check for
    valid IRQs should only accept values > 0.
    
    Fixes: 44dab88e7cc9 ("spi: add spi_ppc4xx driver")
    Signed-off-by: Ma Ke <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Fri Sep 6 10:12:51 2024 +0800

    spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time
    
    [ Upstream commit 3b577de206d52dbde9428664b6d823d35a803d75 ]
    
    It's important to undo pm_runtime_use_autosuspend() with
    pm_runtime_dont_use_autosuspend() at driver exit time unless driver
    initially enabled pm_runtime with devm_pm_runtime_enable()
    (which handles it for you).
    
    Hence, call pm_runtime_dont_use_autosuspend() at driver exit time
    to fix it.
    
    Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi")
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: check skb is non-NULL in tcp_rto_delta_us() [+ + +]
Author: Josh Hunt <[email protected]>
Date:   Tue Sep 10 15:08:22 2024 -0400

    tcp: check skb is non-NULL in tcp_rto_delta_us()
    
    [ Upstream commit c8770db2d54437a5f49417ae7b46f7de23d14db6 ]
    
    We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
    kernel that are running ceph and recently hit a null ptr dereference in
    tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
    saw it getting hit from the RACK case as well. Here are examples of the oops
    messages we saw in each of those cases:
    
    Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
    Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
    Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
    Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
    Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
    Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
    Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
    Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
    Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
    Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
    Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
    Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
    Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
    Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
    Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
    Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
    Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
    Jul 26 15:05:02 rx [11061395.916786] Call Trace:
    Jul 26 15:05:02 rx [11061395.919488]
    Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
    Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
    Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
    Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
    Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
    Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
    Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
    Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
    Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
    Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
    Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
    Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
    Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
    Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
    Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
    Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
    Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
    Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
    Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
    Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
    Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_event+0x21/0x30
    Jul 26 15:05:02 rx [11061396.021984] ? clockevents_program_event+0x8f/0xe0
    Jul 26 15:05:02 rx [11061396.027035] run_timer_softirq+0x2a/0x50
    Jul 26 15:05:02 rx [11061396.031212] __do_softirq+0xd1/0x2c1
    Jul 26 15:05:02 rx [11061396.035044] do_softirq_own_stack+0x2a/0x40
    Jul 26 15:05:02 rx [11061396.039480]
    Jul 26 15:05:02 rx [11061396.041840] do_softirq.part.0+0x46/0x50
    Jul 26 15:05:02 rx [11061396.046022] __local_bh_enable_ip+0x50/0x60
    Jul 26 15:05:02 rx [11061396.050460] _raw_spin_unlock_bh+0x1e/0x20
    Jul 26 15:05:02 rx [11061396.054817] nf_conntrack_tcp_packet+0x29e/0xbe0 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.060994] ? get_l4proto+0xe7/0x190 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.066220] nf_conntrack_in+0xe9/0x670 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.071618] ipv6_conntrack_local+0x14/0x20 [nf_conntrack]
    Jul 26 15:05:02 rx [11061396.077356] nf_hook_slow+0x45/0xb0
    Jul 26 15:05:02 rx [11061396.081098] ip6_xmit+0x3f0/0x5d0
    Jul 26 15:05:02 rx [11061396.084670] ? ipv6_anycast_cleanup+0x50/0x50
    Jul 26 15:05:02 rx [11061396.089282] ? __sk_dst_check+0x38/0x70
    Jul 26 15:05:02 rx [11061396.093381] ? inet6_csk_route_socket+0x13b/0x200
    Jul 26 15:05:02 rx [11061396.098346] inet6_csk_xmit+0xa7/0xf0
    Jul 26 15:05:02 rx [11061396.102263] __tcp_transmit_skb+0x550/0xb30
    Jul 26 15:05:02 rx [11061396.106701] tcp_write_xmit+0x3c6/0xc20
    Jul 26 15:05:02 rx [11061396.110792] ? __alloc_skb+0x98/0x1d0
    Jul 26 15:05:02 rx [11061396.114708] __tcp_push_pending_frames+0x37/0x100
    Jul 26 15:05:02 rx [11061396.119667] tcp_push+0xfd/0x100
    Jul 26 15:05:02 rx [11061396.123150] tcp_sendmsg_locked+0xc70/0xdd0
    Jul 26 15:05:02 rx [11061396.127588] tcp_sendmsg+0x2d/0x50
    Jul 26 15:05:02 rx [11061396.131245] inet6_sendmsg+0x43/0x70
    Jul 26 15:05:02 rx [11061396.135075] __sock_sendmsg+0x48/0x70
    Jul 26 15:05:02 rx [11061396.138994] ____sys_sendmsg+0x212/0x280
    Jul 26 15:05:02 rx [11061396.143172] ___sys_sendmsg+0x88/0xd0
    Jul 26 15:05:02 rx [11061396.147098] ? __seccomp_filter+0x7e/0x6b0
    Jul 26 15:05:02 rx [11061396.151446] ? __switch_to+0x39c/0x460
    Jul 26 15:05:02 rx [11061396.155453] ? __switch_to_asm+0x42/0x80
    Jul 26 15:05:02 rx [11061396.159636] ? __switch_to_asm+0x5a/0x80
    Jul 26 15:05:02 rx [11061396.163816] __sys_sendmsg+0x5c/0xa0
    Jul 26 15:05:02 rx [11061396.167647] __x64_sys_sendmsg+0x1f/0x30
    Jul 26 15:05:02 rx [11061396.171832] do_syscall_64+0x57/0x190
    Jul 26 15:05:02 rx [11061396.175748] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    Jul 26 15:05:02 rx [11061396.181055] RIP: 0033:0x7f1ef692618d
    Jul 26 15:05:02 rx [11061396.184893] Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 ca ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2f 44 89 c7 48 89 44 24 08 e8 fe ee ff ff 48
    Jul 26 15:05:02 rx [11061396.203889] RSP: 002b:00007f1ef4a26aa0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
    Jul 26 15:05:02 rx [11061396.211708] RAX: ffffffffffffffda RBX: 000000000000084b RCX: 00007f1ef692618d
    Jul 26 15:05:02 rx [11061396.219091] RDX: 0000000000004000 RSI: 00007f1ef4a26b10 RDI: 0000000000000275
    Jul 26 15:05:02 rx [11061396.226475] RBP: 0000000000004000 R08: 0000000000000000 R09: 0000000000000020
    Jul 26 15:05:02 rx [11061396.233859] R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000084b
    Jul 26 15:05:02 rx [11061396.241243] R13: 00007f1ef4a26b10 R14: 0000000000000275 R15: 000055592030f1e8
    Jul 26 15:05:02 rx [11061396.248628] Modules linked in: vrf bridge stp llc vxlan ip6_udp_tunnel udp_tunnel nls_iso8859_1 amd64_edac_mod edac_mce_amd kvm_amd kvm crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper wmi_bmof ipmi_ssif input_leds joydev rndis_host cdc_ether usbnet mii ast drm_vram_helper ttm drm_kms_helper i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt ccp mac_hid ipmi_si ipmi_devintf ipmi_msghandler nft_ct sch_fq_codel nf_tables_set nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink ramoops reed_solomon efi_pstore drm ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib_core raid1 mlx5_core hid_generic pci_hyperv_intf crc32_pclmul tls usbhid ahci mlxfw bnxt_en libahci hid nvme i2c_piix4 nvme_core wmi
    Jul 26 15:05:02 rx [11061396.324334] CR2: 0000000000000020
    Jul 26 15:05:02 rx [11061396.327944] ---[ end trace 68a2b679d1cfb4f1 ]---
    Jul 26 15:05:02 rx [11061396.433435] RIP: 0010:tcp_rearm_rto+0xe4/0x160
    Jul 26 15:05:02 rx [11061396.438137] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
    Jul 26 15:05:02 rx [11061396.457144] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
    Jul 26 15:05:02 rx [11061396.462629] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
    Jul 26 15:05:02 rx [11061396.470012] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
    Jul 26 15:05:02 rx [11061396.477396] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
    Jul 26 15:05:02 rx [11061396.484779] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
    Jul 26 15:05:02 rx [11061396.492164] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
    Jul 26 15:05:02 rx [11061396.499547] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
    Jul 26 15:05:02 rx [11061396.507886] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul 26 15:05:02 rx [11061396.513884] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
    Jul 26 15:05:02 rx [11061396.521267] PKRU: 55555554
    Jul 26 15:05:02 rx [11061396.524230] Kernel panic - not syncing: Fatal exception in interrupt
    Jul 26 15:05:02 rx [11061396.530885] Kernel Offset: 0x1b200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    Jul 26 15:05:03 rx [11061396.660181] ---[ end Kernel panic - not syncing: Fatal
     exception in interrupt ]---
    
    After we hit this we disabled TLP by setting tcp_early_retrans to 0 and then hit the crash in the RACK case:
    
    Aug 7 07:26:16 rx [1006006.265582] BUG: kernel NULL pointer dereference, address: 0000000000000020
    Aug 7 07:26:16 rx [1006006.272719] #PF: supervisor read access in kernel mode
    Aug 7 07:26:16 rx [1006006.278030] #PF: error_code(0x0000) - not-present page
    Aug 7 07:26:16 rx [1006006.283343] PGD 0 P4D 0
    Aug 7 07:26:16 rx [1006006.286057] Oops: 0000 [#1] SMP NOPTI
    Aug 7 07:26:16 rx [1006006.289896] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G W 5.4.0-174-generic #193-Ubuntu
    Aug 7 07:26:16 rx [1006006.299107] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
    Aug 7 07:26:16 rx [1006006.309970] RIP: 0010:tcp_rearm_rto+0xe4/0x160
    Aug 7 07:26:16 rx [1006006.314584] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
    Aug 7 07:26:16 rx [1006006.333499] RSP: 0018:ffffb42600a50960 EFLAGS: 00010246
    Aug 7 07:26:16 rx [1006006.338895] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
    Aug 7 07:26:16 rx [1006006.346193] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff92d687ed8160
    Aug 7 07:26:16 rx [1006006.353489] RBP: ffffb42600a50978 R08: 0000000000000000 R09: 00000000cd896dcc
    Aug 7 07:26:16 rx [1006006.360786] R10: ffff92dc3404f400 R11: 0000000000000001 R12: ffff92d687ed8000
    Aug 7 07:26:16 rx [1006006.368084] R13: ffff92d687ed8160 R14: 00000000cd896dcc R15: 00000000cd8fca81
    Aug 7 07:26:16 rx [1006006.375381] FS: 0000000000000000(0000) GS:ffff93158ad40000(0000) knlGS:0000000000000000
    Aug 7 07:26:16 rx [1006006.383632] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Aug 7 07:26:16 rx [1006006.389544] CR2: 0000000000000020 CR3: 0000003e775ce006 CR4: 0000000000760ee0
    Aug 7 07:26:16 rx [1006006.396839] PKRU: 55555554
    Aug 7 07:26:16 rx [1006006.399717] Call Trace:
    Aug 7 07:26:16 rx [1006006.402335]
    Aug 7 07:26:16 rx [1006006.404525] ? show_regs.cold+0x1a/0x1f
    Aug 7 07:26:16 rx [1006006.408532] ? __die+0x90/0xd9
    Aug 7 07:26:16 rx [1006006.411760] ? no_context+0x196/0x380
    Aug 7 07:26:16 rx [1006006.415599] ? __bad_area_nosemaphore+0x50/0x1a0
    Aug 7 07:26:16 rx [1006006.420392] ? _raw_spin_lock+0x1e/0x30
    Aug 7 07:26:16 rx [1006006.424401] ? bad_area_nosemaphore+0x16/0x20
    Aug 7 07:26:16 rx [1006006.428927] ? do_user_addr_fault+0x267/0x450
    Aug 7 07:26:16 rx [1006006.433450] ? __do_page_fault+0x58/0x90
    Aug 7 07:26:16 rx [1006006.437542] ? do_page_fault+0x2c/0xe0
    Aug 7 07:26:16 rx [1006006.441470] ? page_fault+0x34/0x40
    Aug 7 07:26:16 rx [1006006.445134] ? tcp_rearm_rto+0xe4/0x160
    Aug 7 07:26:16 rx [1006006.449145] tcp_ack+0xa32/0xb30
    Aug 7 07:26:16 rx [1006006.452542] tcp_rcv_established+0x13c/0x670
    Aug 7 07:26:16 rx [1006006.456981] ? sk_filter_trim_cap+0x48/0x220
    Aug 7 07:26:16 rx [1006006.461419] tcp_v6_do_rcv+0xdb/0x450
    Aug 7 07:26:16 rx [1006006.465257] tcp_v6_rcv+0xc2b/0xd10
    Aug 7 07:26:16 rx [1006006.468918] ip6_protocol_deliver_rcu+0xd3/0x4e0
    Aug 7 07:26:16 rx [1006006.473706] ip6_input_finish+0x15/0x20
    Aug 7 07:26:16 rx [1006006.477710] ip6_input+0xa2/0xb0
    Aug 7 07:26:16 rx [1006006.481109] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
    Aug 7 07:26:16 rx [1006006.486151] ip6_sublist_rcv_finish+0x3d/0x50
    Aug 7 07:26:16 rx [1006006.490679] ip6_sublist_rcv+0x1aa/0x250
    Aug 7 07:26:16 rx [1006006.494779] ? ip6_rcv_finish_core.isra.0+0xa0/0xa0
    Aug 7 07:26:16 rx [1006006.499828] ipv6_list_rcv+0x112/0x140
    Aug 7 07:26:16 rx [1006006.503748] __netif_receive_skb_list_core+0x1a4/0x250
    Aug 7 07:26:16 rx [1006006.509057] netif_receive_skb_list_internal+0x1a1/0x2b0
    Aug 7 07:26:16 rx [1006006.514538] gro_normal_list.part.0+0x1e/0x40
    Aug 7 07:26:16 rx [1006006.519068] napi_complete_done+0x91/0x130
    Aug 7 07:26:16 rx [1006006.523352] mlx5e_napi_poll+0x18e/0x610 [mlx5_core]
    Aug 7 07:26:16 rx [1006006.528481] net_rx_action+0x142/0x390
    Aug 7 07:26:16 rx [1006006.532398] __do_softirq+0xd1/0x2c1
    Aug 7 07:26:16 rx [1006006.536142] irq_exit+0xae/0xb0
    Aug 7 07:26:16 rx [1006006.539452] do_IRQ+0x5a/0xf0
    Aug 7 07:26:16 rx [1006006.542590] common_interrupt+0xf/0xf
    Aug 7 07:26:16 rx [1006006.546421]
    Aug 7 07:26:16 rx [1006006.548695] RIP: 0010:native_safe_halt+0xe/0x10
    Aug 7 07:26:16 rx [1006006.553399] Code: 7b ff ff ff eb bd 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 36 2c 50 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 26 2c 50 00 fb f4 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 e8 dd 5e 61 ff 65
    Aug 7 07:26:16 rx [1006006.572309] RSP: 0018:ffffb42600177e70 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffc2
    Aug 7 07:26:16 rx [1006006.580040] RAX: ffffffff8ed08b20 RBX: 0000000000000005 RCX: 0000000000000001
    Aug 7 07:26:16 rx [1006006.587337] RDX: 00000000f48eeca2 RSI: 0000000000000082 RDI: 0000000000000082
    Aug 7 07:26:16 rx [1006006.594635] RBP: ffffb42600177e90 R08: 0000000000000000 R09: 000000000000020f
    Aug 7 07:26:16 rx [1006006.601931] R10: 0000000000100000 R11: 0000000000000000 R12: 0000000000000005
    Aug 7 07:26:16 rx [1006006.609229] R13: ffff93157deb5f00 R14: 0000000000000000 R15: 0000000000000000
    Aug 7 07:26:16 rx [1006006.616530] ? __cpuidle_text_start+0x8/0x8
    Aug 7 07:26:16 rx [1006006.620886] ? default_idle+0x20/0x140
    Aug 7 07:26:16 rx [1006006.624804] arch_cpu_idle+0x15/0x20
    Aug 7 07:26:16 rx [1006006.628545] default_idle_call+0x23/0x30
    Aug 7 07:26:16 rx [1006006.632640] do_idle+0x1fb/0x270
    Aug 7 07:26:16 rx [1006006.636035] cpu_startup_entry+0x20/0x30
    Aug 7 07:26:16 rx [1006006.640126] start_secondary+0x178/0x1d0
    Aug 7 07:26:16 rx [1006006.644218] secondary_startup_64+0xa4/0xb0
    Aug 7 07:26:17 rx [1006006.648568] Modules linked in: vrf bridge stp llc vxlan ip6_udp_tunnel udp_tunnel nls_iso8859_1 nft_ct amd64_edac_mod edac_mce_amd kvm_amd kvm crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper wmi_bmof ipmi_ssif input_leds joydev rndis_host cdc_ether usbnet ast mii drm_vram_helper ttm drm_kms_helper i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt ccp mac_hid ipmi_si ipmi_devintf ipmi_msghandler sch_fq_codel nf_tables_set nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink ramoops reed_solomon efi_pstore drm ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid0 multipath linear mlx5_ib ib_uverbs ib_core raid1 hid_generic mlx5_core pci_hyperv_intf crc32_pclmul usbhid ahci tls mlxfw bnxt_en hid libahci nvme i2c_piix4 nvme_core wmi [last unloaded: cpuid]
    Aug 7 07:26:17 rx [1006006.726180] CR2: 0000000000000020
    Aug 7 07:26:17 rx [1006006.729718] ---[ end trace e0e2e37e4e612984 ]---
    
    Prior to seeing the first crash and on other machines we also see the warning in
    tcp_send_loss_probe() where packets_out is non-zero, but both transmit and retrans
    queues are empty so we know the box is seeing some accounting issue in this area:
    
    Jul 26 09:15:27 kernel: ------------[ cut here ]------------
    Jul 26 09:15:27 kernel: invalid inflight: 2 state 1 cwnd 68 mss 8988
    Jul 26 09:15:27 kernel: WARNING: CPU: 16 PID: 0 at net/ipv4/tcp_output.c:2605 tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: Modules linked in: vrf bridge stp llc vxlan ip6_udp_tunnel udp_tunnel nls_iso8859_1 nft_ct amd64_edac_mod edac_mce_amd kvm_amd kvm crct10dif_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper wmi_bmof ipmi_ssif joydev input_leds rndis_host cdc_ether usbnet mii ast drm_vram_helper ttm drm_kms_he>
    Jul 26 09:15:27 kernel: CPU: 16 PID: 0 Comm: swapper/16 Not tainted 5.4.0-174-generic #193-Ubuntu
    Jul 26 09:15:27 kernel: Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
    Jul 26 09:15:27 kernel: RIP: 0010:tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: Code: 08 26 01 00 75 e2 41 0f b6 54 24 12 41 8b 8c 24 c0 06 00 00 45 89 f0 48 c7 c7 e0 b4 20 a7 c6 05 8d 08 26 01 01 e8 4a c0 0f 00 <0f> 0b eb ba 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
    Jul 26 09:15:27 kernel: RSP: 0018:ffffb7838088ce00 EFLAGS: 00010286
    Jul 26 09:15:27 kernel: RAX: 0000000000000000 RBX: ffff9b84b5630430 RCX: 0000000000000006
    Jul 26 09:15:27 kernel: RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff9b8e4621c8c0
    Jul 26 09:15:27 kernel: RBP: ffffb7838088ce18 R08: 0000000000000927 R09: 0000000000000004
    Jul 26 09:15:27 kernel: R10: 0000000000000000 R11: 0000000000000001 R12: ffff9b84b5630000
    Jul 26 09:15:27 kernel: R13: 0000000000000000 R14: 000000000000231c R15: ffff9b84b5630430
    Jul 26 09:15:27 kernel: FS: 0000000000000000(0000) GS:ffff9b8e46200000(0000) knlGS:0000000000000000
    Jul 26 09:15:27 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    Jul 26 09:15:27 kernel: CR2: 000056238cec2380 CR3: 0000003e49ede005 CR4: 0000000000760ee0
    Jul 26 09:15:27 kernel: PKRU: 55555554
    Jul 26 09:15:27 kernel: Call Trace:
    Jul 26 09:15:27 kernel: <IRQ>
    Jul 26 09:15:27 kernel: ? show_regs.cold+0x1a/0x1f
    Jul 26 09:15:27 kernel: ? __warn+0x98/0xe0
    Jul 26 09:15:27 kernel: ? tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: ? report_bug+0xd1/0x100
    Jul 26 09:15:27 kernel: ? do_error_trap+0x9b/0xc0
    Jul 26 09:15:27 kernel: ? do_invalid_op+0x3c/0x50
    Jul 26 09:15:27 kernel: ? tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: ? invalid_op+0x1e/0x30
    Jul 26 09:15:27 kernel: ? tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: tcp_write_timer_handler+0x1b4/0x240
    Jul 26 09:15:27 kernel: tcp_write_timer+0x9e/0xe0
    Jul 26 09:15:27 kernel: ? tcp_write_timer_handler+0x240/0x240
    Jul 26 09:15:27 kernel: call_timer_fn+0x32/0x130
    Jul 26 09:15:27 kernel: __run_timers.part.0+0x180/0x280
    Jul 26 09:15:27 kernel: ? timerqueue_add+0x9b/0xb0
    Jul 26 09:15:27 kernel: ? enqueue_hrtimer+0x3d/0x90
    Jul 26 09:15:27 kernel: ? do_error_trap+0x9b/0xc0
    Jul 26 09:15:27 kernel: ? do_invalid_op+0x3c/0x50
    Jul 26 09:15:27 kernel: ? tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: ? invalid_op+0x1e/0x30
    Jul 26 09:15:27 kernel: ? tcp_send_loss_probe+0x214/0x220
    Jul 26 09:15:27 kernel: tcp_write_timer_handler+0x1b4/0x240
    Jul 26 09:15:27 kernel: tcp_write_timer+0x9e/0xe0
    Jul 26 09:15:27 kernel: ? tcp_write_timer_handler+0x240/0x240
    Jul 26 09:15:27 kernel: call_timer_fn+0x32/0x130
    Jul 26 09:15:27 kernel: __run_timers.part.0+0x180/0x280
    Jul 26 09:15:27 kernel: ? timerqueue_add+0x9b/0xb0
    Jul 26 09:15:27 kernel: ? enqueue_hrtimer+0x3d/0x90
    Jul 26 09:15:27 kernel: ? recalibrate_cpu_khz+0x10/0x10
    Jul 26 09:15:27 kernel: ? ktime_get+0x3e/0xa0
    Jul 26 09:15:27 kernel: ? native_x2apic_icr_write+0x30/0x30
    Jul 26 09:15:27 kernel: run_timer_softirq+0x2a/0x50
    Jul 26 09:15:27 kernel: __do_softirq+0xd1/0x2c1
    Jul 26 09:15:27 kernel: irq_exit+0xae/0xb0
    Jul 26 09:15:27 kernel: smp_apic_timer_interrupt+0x7b/0x140
    Jul 26 09:15:27 kernel: apic_timer_interrupt+0xf/0x20
    Jul 26 09:15:27 kernel: </IRQ>
    Jul 26 09:15:27 kernel: RIP: 0010:native_safe_halt+0xe/0x10
    Jul 26 09:15:27 kernel: Code: 7b ff ff ff eb bd 90 90 90 90 90 90 e9 07 00 00 00 0f 00 2d 36 2c 50 00 f4 c3 66 90 e9 07 00 00 00 0f 00 2d 26 2c 50 00 fb f4 <c3> 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 e8 dd 5e 61 ff 65
    Jul 26 09:15:27 kernel: RSP: 0018:ffffb783801cfe70 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
    Jul 26 09:15:27 kernel: RAX: ffffffffa6908b20 RBX: 0000000000000010 RCX: 0000000000000001
    Jul 26 09:15:27 kernel: RDX: 000000006fc0c97e RSI: 0000000000000082 RDI: 0000000000000082
    Jul 26 09:15:27 kernel: RBP: ffffb783801cfe90 R08: 0000000000000000 R09: 0000000000000225
    Jul 26 09:15:27 kernel: R10: 0000000000100000 R11: 0000000000000000 R12: 0000000000000010
    Jul 26 09:15:27 kernel: R13: ffff9b8e390b0000 R14: 0000000000000000 R15: 0000000000000000
    Jul 26 09:15:27 kernel: ? __cpuidle_text_start+0x8/0x8
    Jul 26 09:15:27 kernel: ? default_idle+0x20/0x140
    Jul 26 09:15:27 kernel: arch_cpu_idle+0x15/0x20
    Jul 26 09:15:27 kernel: default_idle_call+0x23/0x30
    Jul 26 09:15:27 kernel: do_idle+0x1fb/0x270
    Jul 26 09:15:27 kernel: cpu_startup_entry+0x20/0x30
    Jul 26 09:15:27 kernel: start_secondary+0x178/0x1d0
    Jul 26 09:15:27 kernel: secondary_startup_64+0xa4/0xb0
    Jul 26 09:15:27 kernel: ---[ end trace e7ac822987e33be1 ]---
    
    The NULL ptr deref is coming from tcp_rto_delta_us() attempting to pull an skb
    off the head of the retransmit queue and then dereferencing that skb to get the
    skb_mstamp_ns value via tcp_skb_timestamp_us(skb).
    
    The crash is the same one that was reported a # of years ago here:
    https://lore.kernel.org/netdev/[email protected]/T/#t
    
    and the kernel we're running has the fix which was added to resolve this issue.
    
    Unfortunately we've been unsuccessful so far in reproducing this problem in the
    lab and do not have the luxury of pushing out a new kernel to try and test if
    newer kernels resolve this issue at the moment. I realize this is a report
    against both an Ubuntu kernel and also an older 5.4 kernel. I have reported this
    issue to Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077657
    however I feel like since this issue has possibly cropped up again it makes
    sense to build in some protection in this path (even on the latest kernel
    versions) since the code in question just blindly assumes there's a valid skb
    without testing if it's NULL b/f it looks at the timestamp.
    
    Given we have seen crashes in this path before and now this case it seems like
    we should protect ourselves for when packets_out accounting is incorrect.
    While we should fix that root cause we should also just make sure the skb
    is not NULL before dereferencing it. Also add a warn once here to capture
    some information if/when the problem case is hit again.
    
    Fixes: e1a10ef7fa87 ("tcp: introduce tcp_rto_delta_us() helper for xmit timer fix")
    Signed-off-by: Josh Hunt <[email protected]>
    Acked-by: Neal Cardwell <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
thunderbolt: Add support for asymmetric link [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:07 2024 +0000

    thunderbolt: Add support for asymmetric link
    
    [ Upstream commit 81af2952e60603d12415e1a6fd200f8073a2ad8b ]
    
    USB4 v2 spec defines a Gen 4 link that can operate as an aggregated
    symmetric (80/80G) or asymmetric (120/40G). When the link is asymmetric,
    the USB4 port on one side of the link operates with three TX lanes and
    one RX lane, while the USB4 port on the opposite side of the link
    operates with three RX lanes and one TX lane.
    
    Add support for the asymmetric link and provide functions that can be
    used to transition the link to asymmetric and back.
    
    Signed-off-by: Gil Fine <[email protected]>
    Co-developed-by: Mika Westerberg <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Change bandwidth reservations to comply USB4 v2 [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:03 2024 +0000

    thunderbolt: Change bandwidth reservations to comply USB4 v2
    
    [ Upstream commit 582e70b0d3a412d15389a3c9c07a44791b311715 ]
    
    USB4 v2 Connection Manager guide (section 6.1.2.3) suggests to reserve
    bandwidth in a sligthly different manner. It suggests to keep minimum of
    1500 Mb/s for each path that carry a bulk traffic. Here we change the
    bandwidth reservations to comply to the above for USB 3.x and PCIe
    protocols over Gen 4 link, taking weights into account (that's 1500 Mb/s
    for PCIe and 3000 Mb/s for USB 3.x).
    
    For Gen 3 and below we use the existing reservation.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Configure asymmetric link if needed and bandwidth allows [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:08 2024 +0000

    thunderbolt: Configure asymmetric link if needed and bandwidth allows
    
    [ Upstream commit 3e36528c1127b20492ffaea53930bcc3df46a718 ]
    
    USB4 v2 spec defines a Gen 4 link that can operate as an asymmetric
    120/40G. When the link is asymmetric, the USB4 port on one side of the
    link operates with three TX lanes and one RX lane, while the USB4 port
    on the opposite side of the link operates with three RX lanes and one TX
    lane. Using asymmetric link we can get much more bandwidth from one
    direction and that allows us to support the new Ultra High Bit Rate
    DisplayPort modes (that consume up to 77.37 Gb/s).
    
    Add the basic logic for changing Gen 4 links to asymmetric and back
    following the below rules:
    
      1) The default threshold is 45 Gb/s (tunable by asym_threshold)
      2) When DisplayPort tunnel is established, or when there is bandwidth
         request through bandwidth allocation mode, the links can be
         transitioned to asymmetric or symmetric (depending on the
         required bandwidth).
      3) Only DisplayPort bandwidth on a link, is taken into account when
         deciding whether a link is transitioned to asymmetric or symmetric
      4) If bandwidth on a link is >= asym_threshold transition the link to
         asymmetric
      5) If bandwidth on a link < asym_threshold transition the link to
         symmetric (unless the bandwidth request is above currently
         allocated on a tunnel).
      6) If a USB4 v2 device router with symmetric link is connected,
         transition all the links above it to symmetric if the bandwidth
         allows.
    
    Signed-off-by: Gil Fine <[email protected]>
    Co-developed-by: Mika Westerberg <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Create multiple DisplayPort tunnels if there are more DP IN/OUT pairs [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:30:59 2024 +0000

    thunderbolt: Create multiple DisplayPort tunnels if there are more DP IN/OUT pairs
    
    [ Upstream commit 8648c6465c025c488e2855c209c0dea1a1a15184 ]
    
    Currently we only create one DisplayPort tunnel even if there would be
    more DP IN/OUT pairs available. Specifically this happens when a router
    is unplugged and we check if a new DisplayPort tunnel can be created. To
    cover this create tunnels as long as we find suitable DP IN/OUT pairs.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Expose tb_tunnel_xxx() log macros to the rest of the driver [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:30:58 2024 +0000

    thunderbolt: Expose tb_tunnel_xxx() log macros to the rest of the driver
    
    [ Upstream commit d27bd2c37d4666bce25ec4d9ac8c6b169992f0f0 ]
    
    In order to allow more consistent logging of tunnel related information
    make these logging macros available to the rest of the driver.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Fix debug log when DisplayPort adapter not available for pairing [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:30:56 2024 +0000

    thunderbolt: Fix debug log when DisplayPort adapter not available for pairing
    
    [ Upstream commit 6b8ac54f31f985d3abb0b4212187838dd8ea4227 ]
    
    Fix debug log when looking for a DisplayPort adapter pair of DP IN and
    DP OUT. In case of no DP adapter available, log the type of the DP
    adapter that is not available.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Fix minimum allocated USB 3.x and PCIe bandwidth [+ + +]
Author: Gil Fine <[email protected]>
Date:   Thu Nov 30 18:17:13 2023 +0200

    thunderbolt: Fix minimum allocated USB 3.x and PCIe bandwidth
    
    commit f0b94c1c5c7994a74e487f43c91cfc922105a423 upstream.
    
    With the current bandwidth allocation we end up reserving too much for the USB
    3.x and PCIe tunnels that leads to reduced capabilities for the second
    DisplayPort tunnel.
    
    Fix this by decreasing the USB 3.x allocation to 900 Mb/s which then allows
    both tunnels to get the maximum HBR2 bandwidth.  This way, the reserved
    bandwidth for USB 3.x and PCIe, would be 1350 Mb/s (taking weights of USB 3.x
    and PCIe into account). So bandwidth allocations on a link are:
    USB 3.x + PCIe tunnels => 1350 Mb/s
    DisplayPort tunnel #1  => 17280 Mb/s
    DisplayPort tunnel #2  => 17280 Mb/s
    
    Total consumed bandwidth is 35910 Mb/s. So that all the above can be tunneled
    on a Gen 3 link (which allows maximum of 36000 Mb/s).
    
    Fixes: 582e70b0d3a4 ("thunderbolt: Change bandwidth reservations to comply USB4 v2")
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Fix NULL pointer dereference in tb_port_update_credits() [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Mon Feb 12 13:03:34 2024 +0200

    thunderbolt: Fix NULL pointer dereference in tb_port_update_credits()
    
    commit d3d17e23d1a0d1f959b4fa55b35f1802d9c584fa upstream.
    
    Olliver reported that his system crashes when plugging in Thunderbolt 1
    device:
    
     BUG: kernel NULL pointer dereference, address: 0000000000000020
     #PF: supervisor read access in kernel mode
     #PF: error_code(0x0000) - not-present page
     PGD 0 P4D 0
     Oops: 0000 [#1] PREEMPT SMP NOPTI
     RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt]
     Call Trace:
      <TASK>
      ? __die+0x23/0x70
      ? page_fault_oops+0x171/0x4e0
      ? exc_page_fault+0x7f/0x180
      ? asm_exc_page_fault+0x26/0x30
      ? tb_port_do_update_credits+0x1b/0x130
      ? tb_switch_update_link_attributes+0x83/0xd0
      tb_switch_add+0x7a2/0xfe0
      tb_scan_port+0x236/0x6f0
      tb_handle_hotplug+0x6db/0x900
      process_one_work+0x171/0x340
      worker_thread+0x27b/0x3a0
      ? __pfx_worker_thread+0x10/0x10
      kthread+0xe5/0x120
      ? __pfx_kthread+0x10/0x10
      ret_from_fork+0x31/0x50
      ? __pfx_kthread+0x10/0x10
      ret_from_fork_asm+0x1b/0x30
      </TASK>
    
    This is due the fact that some Thunderbolt 1 devices only have one lane
    adapter. Fix this by checking for the lane 1 before we read its credits.
    
    Reported-by: Olliver Schinagl <[email protected]>
    Closes: https://lore.kernel.org/linux-usb/[email protected]/
    Fixes: 81af2952e606 ("thunderbolt: Add support for asymmetric link")
    Cc: [email protected]
    Cc: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Improve DisplayPort tunnel setup process to be more robust [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:09 2024 +0000

    thunderbolt: Improve DisplayPort tunnel setup process to be more robust
    
    [ Upstream commit b4734507ac55cc7ea1380e20e83f60fcd7031955 ]
    
    After DisplayPort tunnel setup, we add verification that the DPRX
    capabilities read process completed. Otherwise, we bail out, teardown
    the tunnel, and try setup another DisplayPort tunnel using next
    available DP IN adapter. We do so till all DP IN adapters tried. This
    way, we avoid allocating DP IN adapter and (bandwidth for it) for
    unusable tunnel.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Introduce tb_for_each_upstream_port_on_path() [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:31:05 2024 +0000

    thunderbolt: Introduce tb_for_each_upstream_port_on_path()
    
    [ Upstream commit 956c3abe72fb6a651b8cf77c28462f7e5b6a48b1 ]
    
    This is useful when walking over upstream lane adapters over given path.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Introduce tb_port_path_direction_downstream() [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:04 2024 +0000

    thunderbolt: Introduce tb_port_path_direction_downstream()
    
    [ Upstream commit 2bfeca73e94567c1a117ca45d2e8a25d63e5bd2c ]
    
    Introduce tb_port_path_direction_downstream() to check if path from
    source adapter to destination adapter is directed towards downstream.
    Convert existing users to call this helper instead of open-coding.
    
    No functional changes.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Introduce tb_switch_depth() [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:31:06 2024 +0000

    thunderbolt: Introduce tb_switch_depth()
    
    [ Upstream commit c4ff14436952c3d0dd05769d76cf48e73a253b48 ]
    
    This is useful helper to find out the depth of a connected router.
    Convert the existing users to call this helper instead of open-coding.
    
    No functional changes.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Make is_gen4_link() available to the rest of the driver [+ + +]
Author: Gil Fine <[email protected]>
Date:   Tue Oct 1 17:31:02 2024 +0000

    thunderbolt: Make is_gen4_link() available to the rest of the driver
    
    [ Upstream commit aa673d606078da36ebc379f041c794228ac08cb5 ]
    
    Rework the function to return the link generation, update the name to
    tb_port_get_link_generation(), and make available to the rest of the
    driver. This is needed in the subsequent patches.
    
    Signed-off-by: Gil Fine <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Send uevent after asymmetric/symmetric switch [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Nov 7 14:34:27 2023 +0200

    thunderbolt: Send uevent after asymmetric/symmetric switch
    
    commit 5391bcfa56c79a891734e4d22aa0ca3217b86491 upstream.
    
    We should send uevent to userspace whenever the link speed or width
    changes but tb_switch_asym_enable() and tb_switch_asym_disable() set the
    sw->link_width already so tb_switch_update_link_attributes() never
    noticed the change.
    
    Fix this so that we let tb_switch_update_link_attributes() update the
    fields accordingly.
    
    Fixes: 81af2952e606 ("thunderbolt: Add support for asymmetric link")
    Reported-by: Pengfei Xu <[email protected]>
    Tested-by: Pengfei Xu <[email protected]>
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Use constants for path weight and priority [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:31:00 2024 +0000

    thunderbolt: Use constants for path weight and priority
    
    [ Upstream commit f73edddfa2a64a185c65a33f100778169c92fc25 ]
    
    Makes it easier to follow and update. No functional changes.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Use tb_tunnel_dbg() where possible to make logging more consistent [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:30:57 2024 +0000

    thunderbolt: Use tb_tunnel_dbg() where possible to make logging more consistent
    
    [ Upstream commit fe8a0293c922ee8bc1ff0cf9048075afb264004a ]
    
    This makes it easier to find out the tunnel in question. Also drop a
    couple of lines that generate duplicate information.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

thunderbolt: Use weight constants in tb_usb3_consumed_bandwidth() [+ + +]
Author: Mika Westerberg <[email protected]>
Date:   Tue Oct 1 17:31:01 2024 +0000

    thunderbolt: Use weight constants in tb_usb3_consumed_bandwidth()
    
    [ Upstream commit 4d24db0c801461adeefd7e0bdc98c79c60ccefb0 ]
    
    Instead of magic numbers use the constants we introduced in the previous
    commit to make the code more readable. No functional changes.
    
    Signed-off-by: Mika Westerberg <[email protected]>
    Signed-off-by: Qin Wan <[email protected]>
    Signed-off-by: Alexandru Gagniuc <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tools/runqslower: Fix LDFLAGS and add LDLIBS support [+ + +]
Author: Tony Ambardar <[email protected]>
Date:   Mon Jul 22 17:30:45 2024 -0700

    tools/runqslower: Fix LDFLAGS and add LDLIBS support
    
    [ Upstream commit f86601c3661946721e8f260bdd812b759854ac22 ]
    
    Actually use previously defined LDFLAGS during build and add support for
    LDLIBS to link extra standalone libraries e.g. 'argp' which is not provided
    by musl libc.
    
    Fixes: 585bf4640ebe ("tools: runqslower: Add EXTRA_CFLAGS and EXTRA_LDFLAGS support")
    Signed-off-by: Tony Ambardar <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Acked-by: Ilya Leoshkevich <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
tpm: Clean up TPM space after command failure [+ + +]
Author: Jonathan McDowell <[email protected]>
Date:   Fri Aug 16 12:55:46 2024 +0100

    tpm: Clean up TPM space after command failure
    
    [ Upstream commit e3aaebcbb7c6b403416f442d1de70d437ce313a7 ]
    
    tpm_dev_transmit prepares the TPM space before attempting command
    transmission. However if the command fails no rollback of this
    preparation is done. This can result in transient handles being leaked
    if the device is subsequently closed with no further commands performed.
    
    Fix this by flushing the space in the event of command transmission
    failure.
    
    Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces")
    Signed-off-by: Jonathan McDowell <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Jarkko Sakkinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: rp2: Fix reset with non forgiving PCIe host bridges [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Fri Sep 6 15:54:33 2024 -0700

    tty: rp2: Fix reset with non forgiving PCIe host bridges
    
    commit f16dd10ba342c429b1e36ada545fb36d4d1f0e63 upstream.
    
    The write to RP2_GLOBAL_CMD followed by an immediate read of
    RP2_GLOBAL_CMD in rp2_reset_asic() is intented to flush out the write,
    however by then the device is already in reset and cannot respond to a
    memory cycle access.
    
    On platforms such as the Raspberry Pi 4 and others using the
    pcie-brcmstb.c driver, any memory access to a device that cannot respond
    is met with a fatal system error, rather than being substituted with all
    1s as is usually the case on PC platforms.
    
    Swapping the delay and the read ensures that the device has finished
    resetting before we attempt to read from it.
    
    Fixes: 7d9f49afa451 ("serial: rp2: New driver for Comtrol RocketPort 2 cards")
    Cc: stable <[email protected]>
    Suggested-by: Jim Quinlan <[email protected]>
    Signed-off-by: Florian Fainelli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

tty: serial: kgdboc: Fix 8250_* kgdb over serial [+ + +]
Author: Michael Trimarchi <[email protected]>
Date:   Sun Dec 24 14:12:00 2023 +0100

    tty: serial: kgdboc: Fix 8250_* kgdb over serial
    
    [ Upstream commit 788aeef392d27545ae99af2875068a9dd0531d5f ]
    
    Check if port type is not PORT_UNKNOWN during poll_init.
    The kgdboc calls the tty_find_polling_driver that check
    if the serial is able to use poll_init. The poll_init calls
    the uart uart_poll_init that try to configure the uart with the
    selected boot parameters. The uart must be ready before setting
    parameters. Seems that PORT_UNKNOWN is already used by other
    functions in serial_core to detect uart status, so use the same
    to avoid to use it in invalid state.
    
    The crash happen for instance in am62x architecture where the 8250
    register the platform driver after the 8250 core is initialized.
    
    Follow the report crash coming from KGDB
    
    Thread 2 received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 1]
    _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584
    584             __raw_writeb(value, PCI_IOBASE + addr);
    (gdb) bt
    
    This section of the code is too early because in this case
    the omap serial is not probed
    
    Thread 2 received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 1]
    _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584
    584             __raw_writeb(value, PCI_IOBASE + addr);
    (gdb) bt
    
    Thread 2 received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 1]
    _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584
    584             __raw_writeb(value, PCI_IOBASE + addr);
    (gdb) bt
    0  _outb (addr=<optimized out>, value=<optimized out>) at ./include/asm-generic/io.h:584
    1  logic_outb (value=0 '\000', addr=18446739675637874689) at lib/logic_pio.c:299
    2  0xffff80008082dfcc in io_serial_out (p=0x0, offset=16760830, value=0) at drivers/tty/serial/8250/8250_port.c:416
    3  0xffff80008082fe34 in serial_port_out (value=<optimized out>, offset=<optimized out>, up=<optimized out>)
        at ./include/linux/serial_core.h:677
    4  serial8250_do_set_termios (port=0xffff8000828ee940 <serial8250_ports+1568>, termios=0xffff80008292b93c, old=0x0)
        at drivers/tty/serial/8250/8250_port.c:2860
    5  0xffff800080830064 in serial8250_set_termios (port=0xfffffbfffe800000, termios=0xffbffe, old=0x0)
        at drivers/tty/serial/8250/8250_port.c:2912
    6  0xffff80008082571c in uart_set_options (port=0xffff8000828ee940 <serial8250_ports+1568>, co=0x0, baud=115200, parity=110, bits=8, flow=110)
        at drivers/tty/serial/serial_core.c:2285
    7  0xffff800080828434 in uart_poll_init (driver=0xfffffbfffe800000, line=16760830, options=0xffff8000828f7506 <config+6> "115200n8")
        at drivers/tty/serial/serial_core.c:2656
    8  0xffff800080801690 in tty_find_polling_driver (name=0xffff8000828f7500 <config> "ttyS2,115200n8", line=0xffff80008292ba90)
        at drivers/tty/tty_io.c:410
    9  0xffff80008086c0b0 in configure_kgdboc () at drivers/tty/serial/kgdboc.c:194
    10 0xffff80008086c1ec in kgdboc_probe (pdev=0xfffffbfffe800000) at drivers/tty/serial/kgdboc.c:249
    11 0xffff8000808b399c in platform_probe (_dev=0xffff000000ebb810) at drivers/base/platform.c:1404
    12 0xffff8000808b0b44 in call_driver_probe (drv=<optimized out>, dev=<optimized out>) at drivers/base/dd.c:579
    13 really_probe (dev=0xffff000000ebb810, drv=0xffff80008277f138 <kgdboc_platform_driver+48>) at drivers/base/dd.c:658
    14 0xffff8000808b0d2c in __driver_probe_device (drv=0xffff80008277f138 <kgdboc_platform_driver+48>, dev=0xffff000000ebb810)
        at drivers/base/dd.c:800
    15 0xffff8000808b0eb8 in driver_probe_device (drv=0xfffffbfffe800000, dev=0xffff000000ebb810) at drivers/base/dd.c:830
    16 0xffff8000808b0ff4 in __device_attach_driver (drv=0xffff80008277f138 <kgdboc_platform_driver+48>, _data=0xffff80008292bc48)
        at drivers/base/dd.c:958
    17 0xffff8000808ae970 in bus_for_each_drv (bus=0xfffffbfffe800000, start=0x0, data=0xffff80008292bc48,
        fn=0xffff8000808b0f3c <__device_attach_driver>) at drivers/base/bus.c:457
    18 0xffff8000808b1408 in __device_attach (dev=0xffff000000ebb810, allow_async=true) at drivers/base/dd.c:1030
    19 0xffff8000808b16d8 in device_initial_probe (dev=0xfffffbfffe800000) at drivers/base/dd.c:1079
    20 0xffff8000808af9f4 in bus_probe_device (dev=0xffff000000ebb810) at drivers/base/bus.c:532
    21 0xffff8000808ac77c in device_add (dev=0xfffffbfffe800000) at drivers/base/core.c:3625
    22 0xffff8000808b3428 in platform_device_add (pdev=0xffff000000ebb800) at drivers/base/platform.c:716
    23 0xffff800081b5dc0c in init_kgdboc () at drivers/tty/serial/kgdboc.c:292
    24 0xffff800080014db0 in do_one_initcall (fn=0xffff800081b5dba4 <init_kgdboc>) at init/main.c:1236
    25 0xffff800081b0114c in do_initcall_level (command_line=<optimized out>, level=<optimized out>) at init/main.c:1298
    26 do_initcalls () at init/main.c:1314
    27 do_basic_setup () at init/main.c:1333
    28 kernel_init_freeable () at init/main.c:1551
    29 0xffff8000810271ec in kernel_init (unused=0xfffffbfffe800000) at init/main.c:1441
    30 0xffff800080015e80 in ret_from_fork () at arch/arm64/kernel/entry.S:857
    
    Reviewed-by: Douglas Anderson <[email protected]>
    Signed-off-by: Michael Trimarchi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: d0009a32c9e4 ("serial: don't use uninitialized value in uart_poll_init()")
    Signed-off-by: Sasha Levin <[email protected]>

 
ublk: move zone report data out of request pdu [+ + +]
Author: Ming Lei <[email protected]>
Date:   Mon Aug 12 09:36:24 2024 +0800

    ublk: move zone report data out of request pdu
    
    [ Upstream commit 9327b51c9a9c864f5177127e09851da9d78b4943 ]
    
    ublk zoned takes 16 bytes in each request pdu just for handling REPORT_ZONE
    operation, this way does waste memory since request pdu is allocated
    statically.
    
    Store the transient zone report data into one global xarray, and remove
    it after the report zone request is completed. This way is reasonable
    since report zone is run in slow code path.
    
    Fixes: 29802d7ca33b ("ublk: enable zoned storage support")
    Cc: Damien Le Moal <[email protected]>
    Cc: Andreas Hindborg <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
USB: appledisplay: close race between probe and completion handler [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Sep 12 14:32:59 2024 +0200

    USB: appledisplay: close race between probe and completion handler
    
    commit 8265d06b7794493d82c5c21a12d7ba43eccc30cb upstream.
    
    There is a small window during probing when IO is running
    but the backlight is not registered. Processing events
    during that time will crash. The completion handler
    needs to check for a backlight before scheduling work.
    
    The bug is as old as the driver.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    CC: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: cdnsp: Fix incorrect usb_request status [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Fri Sep 6 06:48:54 2024 +0000

    usb: cdnsp: Fix incorrect usb_request status
    
    commit 1702bec4477cc7d31adb4a760d14d33fac928b7a upstream.
    
    Fix changes incorrect usb_request->status returned during disabling
    endpoints. Before fix the status returned during dequeuing requests
    while disabling endpoint was ECONNRESET.
    Patch change it to ESHUTDOWN.
    
    Patch fixes issue detected during testing UVC gadget.
    During stopping streaming the class starts dequeuing usb requests and
    controller driver returns the -ECONNRESET status. After completion
    requests the class or application "uvc-gadget" try to queue this
    request again. Changing this status to ESHUTDOWN cause that UVC assumes
    that endpoint is disabled, or device is disconnected and stops
    re-queuing usb requests.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: [email protected]
    Signed-off-by: Pawel Laszczak <[email protected]>
    Reviewed-by: Peter Chen <[email protected]>
    Link: https://lore.kernel.org/r/PH7PR07MB9538E8CA7A2096AAF6A3718FDD9E2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: class: CDC-ACM: fix race between get_serial and set_serial [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Sep 12 16:19:06 2024 +0200

    USB: class: CDC-ACM: fix race between get_serial and set_serial
    
    commit b41c1fa155ba56d125885b0191aabaf3c508d0a3 upstream.
    
    TIOCGSERIAL is an ioctl. Thus it must be atomic. It returns
    two values. Racing with set_serial it can return an inconsistent
    result. The mutex must be taken.
    
    In terms of logic the bug is as old as the driver. In terms of
    code it goes back to the conversion to the get_serial and
    set_serial methods.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Cc: stable <[email protected]>
    Fixes: 99f75a1fcd865 ("cdc-acm: switch to ->[sg]et_serial()")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: dwc2: drd: fix clock gating on USB role switch [+ + +]
Author: Tomas Marek <[email protected]>
Date:   Fri Sep 6 07:50:25 2024 +0200

    usb: dwc2: drd: fix clock gating on USB role switch
    
    commit 2c6b6afa59e78bebcb65bbc8a76b3459f139547c upstream.
    
    The dwc2_handle_usb_suspend_intr() function disables gadget clocks in USB
    peripheral mode when no other power-down mode is available (introduced by
    commit 0112b7ce68ea ("usb: dwc2: Update dwc2_handle_usb_suspend_intr function.")).
    However, the dwc2_drd_role_sw_set() USB role update handler attempts to
    read DWC2 registers if the USB role has changed while the USB is in suspend
    mode (when the clocks are gated). This causes the system to hang.
    
    Release the gadget clocks before handling the USB role update.
    
    Fixes: 0112b7ce68ea ("usb: dwc2: Update dwc2_handle_usb_suspend_intr function.")
    Cc: [email protected]
    Signed-off-by: Tomas Marek <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: misc: cypress_cy7c63: check for short transfer [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Sep 12 14:54:43 2024 +0200

    USB: misc: cypress_cy7c63: check for short transfer
    
    commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream.
    
    As we process the second byte of a control transfer, transfers
    of less than 2 bytes must be discarded.
    
    This bug is as old as the driver.
    
    SIgned-off-by: Oliver Neukum <[email protected]>
    CC: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

USB: misc: yurex: fix race between read and write [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Sep 12 15:21:22 2024 +0200

    USB: misc: yurex: fix race between read and write
    
    [ Upstream commit 93907620b308609c72ba4b95b09a6aa2658bb553 ]
    
    The write code path touches the bbu member in a non atomic manner
    without taking the spinlock. Fix it.
    
    The bug is as old as the driver.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    CC: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: xhci: fix loss of data on Cadence xHC [+ + +]
Author: Pawel Laszczak <[email protected]>
Date:   Thu Sep 5 07:03:28 2024 +0000

    usb: xhci: fix loss of data on Cadence xHC
    
    [ Upstream commit e5fa8db0be3e8757e8641600c518425a4589b85c ]
    
    Streams should flush their TRB cache, re-read TRBs, and start executing
    TRBs from the beginning of the new dequeue pointer after a 'Set TR Dequeue
    Pointer' command.
    
    Cadence controllers may fail to start from the beginning of the dequeue
    TRB as it doesn't clear the Opaque 'RsvdO' field of the stream context
    during 'Set TR Dequeue' command. This stream context area is where xHC
    stores information about the last partially executed TD when a stream
    is stopped. xHC uses this information to resume the transfer where it left
    mid TD, when the stream is restarted.
    
    Patch fixes this by clearing out all RsvdO fields before initializing new
    Stream transfer using a 'Set TR Dequeue Pointer' command.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: [email protected]
    Signed-off-by: Pawel Laszczak <[email protected]>
    Reviewed-by: Peter Chen <[email protected]>
    Link: https://lore.kernel.org/r/PH7PR07MB95386A40146E3EC64086F409DD9D2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: yurex: Fix inconsistent locking bug in yurex_read() [+ + +]
Author: Harshit Mogalapalli <[email protected]>
Date:   Mon Dec 18 22:36:35 2023 -0800

    usb: yurex: Fix inconsistent locking bug in yurex_read()
    
    commit e7d3b9f28654dbfce7e09f8028210489adaf6a33 upstream.
    
    Unlock before returning on the error path.
    
    Fixes: 86b20af11e84 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant")
    Reported-by: Dan Carpenter <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Harshit Mogalapalli <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: yurex: Replace snprintf() with the safer scnprintf() variant [+ + +]
Author: Lee Jones <[email protected]>
Date:   Wed Dec 13 16:42:37 2023 +0000

    usb: yurex: Replace snprintf() with the safer scnprintf() variant
    
    [ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ]
    
    There is a general misunderstanding amongst engineers that {v}snprintf()
    returns the length of the data *actually* encoded into the destination
    array.  However, as per the C99 standard {v}snprintf() really returns
    the length of the data that *would have been* written if there were
    enough space for it.  This misunderstanding has led to buffer-overruns
    in the past.  It's generally considered safer to use the {v}scnprintf()
    variants in their place (or even sprintf() in simple cases).  So let's
    do that.
    
    Whilst we're at it, let's define some magic numbers to increase
    readability and ease of maintenance.
    
    Link: https://lwn.net/Articles/69419/
    Link: https://github.com/KSPP/linux/issues/105
    Cc: Tomoki Sekiyama <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write")
    Signed-off-by: Sasha Levin <[email protected]>

 
usbnet: fix cyclical race on disconnect with work queue [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Sep 19 14:33:42 2024 +0200

    usbnet: fix cyclical race on disconnect with work queue
    
    commit 04e906839a053f092ef53f4fb2d610983412b904 upstream.
    
    The work can submit URBs and the URBs can schedule the work.
    This cycle needs to be broken, when a device is to be stopped.
    Use a flag to do so.
    This is a design issue as old as the driver.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    CC: [email protected]
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vfs: fix race between evice_inodes() and find_inode()&iput() [+ + +]
Author: Julian Sun <[email protected]>
Date:   Fri Aug 23 21:07:30 2024 +0800

    vfs: fix race between evice_inodes() and find_inode()&iput()
    
    commit 88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 upstream.
    
    Hi, all
    
    Recently I noticed a bug[1] in btrfs, after digged it into
    and I believe it'a race in vfs.
    
    Let's assume there's a inode (ie ino 261) with i_count 1 is
    called by iput(), and there's a concurrent thread calling
    generic_shutdown_super().
    
    cpu0:                              cpu1:
    iput() // i_count is 1
      ->spin_lock(inode)
      ->dec i_count to 0
      ->iput_final()                    generic_shutdown_super()
        ->__inode_add_lru()               ->evict_inodes()
          // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;
          // return before                  // inode 261 passed the above check
          // list_lru_add_obj()             // and then schedule out
       ->spin_unlock()
    // note here: the inode 261
    // was still at sb list and hash list,
    // and I_FREEING|I_WILL_FREE was not been set
    
    btrfs_iget()
      // after some function calls
      ->find_inode()
        // found the above inode 261
        ->spin_lock(inode)
       // check I_FREEING|I_WILL_FREE
       // and passed
          ->__iget()
        ->spin_unlock(inode)                // schedule back
                                            ->spin_lock(inode)
                                            // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                            // passed and set I_FREEING
    iput()                                  ->spin_unlock(inode)
      ->spin_lock(inode)                      ->evict()
      // dec i_count to 0
      ->iput_final()
        ->spin_unlock()
        ->evict()
    
    Now, we have two threads simultaneously evicting
    the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
    statement both within clear_inode() and iput().
    
    To fix the bug, recheck the inode->i_count after holding i_lock.
    Because in the most scenarios, the first check is valid, and
    the overhead of spin_lock() can be reduced.
    
    If there is any misunderstanding, please let me know, thanks.
    
    [1]: https://lore.kernel.org/linux-btrfs/[email protected]/
    [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
    return false when I reproduced the bug.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=67ba3c42bcbb4665d3ad
    CC: [email protected]
    Fixes: 63997e98a3be ("split invalidate_inodes()")
    Signed-off-by: Julian Sun <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
vhost_vdpa: assign irq bypass producer token correctly [+ + +]
Author: Jason Wang <[email protected]>
Date:   Fri Aug 16 11:19:00 2024 +0800

    vhost_vdpa: assign irq bypass producer token correctly
    
    [ Upstream commit 02e9e9366fefe461719da5d173385b6685f70319 ]
    
    We used to call irq_bypass_unregister_producer() in
    vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the
    token pointer is still valid or not.
    
    Actually, we use the eventfd_ctx as the token so the life cycle of the
    token should be bound to the VHOST_SET_VRING_CALL instead of
    vhost_vdpa_setup_vq_irq() which could be called by set_status().
    
    Fixing this by setting up irq bypass producer's token when handling
    VHOST_SET_VRING_CALL and un-registering the producer before calling
    vhost_vring_ioctl() to prevent a possible use after free as eventfd
    could have been released in vhost_vring_ioctl(). And such registering
    and unregistering will only be done if DRIVER_OK is set.
    
    Reported-by: Dragos Tatulea <[email protected]>
    Tested-by: Dragos Tatulea <[email protected]>
    Reviewed-by: Dragos Tatulea <[email protected]>
    Fixes: 2cf1ba9a4d15 ("vhost_vdpa: implement IRQ offloading in vhost_vdpa")
    Signed-off-by: Jason Wang <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
virtio_net: Fix mismatched buf address when unmapping for small packets [+ + +]
Author: Wenbo Li <[email protected]>
Date:   Thu Sep 19 16:13:51 2024 +0800

    virtio_net: Fix mismatched buf address when unmapping for small packets
    
    [ Upstream commit c11a49d58ad229a1be1ebe08a2b68fedf83db6c8 ]
    
    Currently, the virtio-net driver will perform a pre-dma-mapping for
    small or mergeable RX buffer. But for small packets, a mismatched address
    without VIRTNET_RX_PAD and xdp_headroom is used for unmapping.
    
    That will result in unsynchronized buffers when SWIOTLB is enabled, for
    example, when running as a TDX guest.
    
    This patch unifies the address passed to the virtio core as the address of
    the virtnet header and fixes the mismatched buffer address.
    
    Changes from v2: unify the buf that passed to the virtio core in small
    and merge mode.
    Changes from v1: Use ctx to get xdp_headroom.
    
    Fixes: 295525e29a5b ("virtio_net: merge dma operations when filling mergeable buffers")
    Signed-off-by: Wenbo Li <[email protected]>
    Signed-off-by: Jiahui Cen <[email protected]>
    Signed-off-by: Ying Fang <[email protected]>
    Reviewed-by: Xuan Zhuo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
watchdog: imx_sc_wdt: Don't disable WDT in suspend [+ + +]
Author: Jonas Blixt <[email protected]>
Date:   Thu Aug 1 14:18:45 2024 +0200

    watchdog: imx_sc_wdt: Don't disable WDT in suspend
    
    [ Upstream commit 2d9d6d300fb0a4ae4431bb308027ac9385746d42 ]
    
    Parts of the suspend and resume chain is left unprotected if we disable
    the WDT here.
    
    >From experiments we can see that the SCU disables and re-enables the WDT
    when we enter and leave suspend to ram. By not touching the WDT here we
    are protected by the WDT all the way to the SCU.
    
    Signed-off-by: Jonas Blixt <[email protected]>
    CC: Anson Huang <[email protected]>
    Fixes: 986857acbc9a ("watchdog: imx_sc: Add i.MX system controller watchdog support")
    Reviewed-by: Guenter Roeck <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Wim Van Sebroeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: ath12k: fix BSS chan info request WMI command [+ + +]
Author: P Praneesh <[email protected]>
Date:   Mon Apr 1 00:02:31 2024 +0530

    wifi: ath12k: fix BSS chan info request WMI command
    
    [ Upstream commit 59529c982f85047650fd473db903b23006a796c6 ]
    
    Currently, the firmware returns incorrect pdev_id information in
    WMI_PDEV_BSS_CHAN_INFO_EVENTID, leading to incorrect filling of
    the pdev's survey information.
    
    To prevent this issue, when requesting BSS channel information
    through WMI_PDEV_BSS_CHAN_INFO_REQUEST_CMDID, firmware expects
    pdev_id as one of the arguments in this WMI command.
    
    Add pdev_id to the struct wmi_pdev_bss_chan_info_req_cmd and fill it
    during ath12k_wmi_pdev_bss_chan_info_request(). This resolves the
    issue of sending the correct pdev_id in WMI_PDEV_BSS_CHAN_INFO_EVENTID.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: P Praneesh <[email protected]>
    Signed-off-by: Karthikeyan Kathirvel <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: fix invalid AMPDU factor calculation in ath12k_peer_assoc_h_he() [+ + +]
Author: Baochen Qiang <[email protected]>
Date:   Wed Jul 10 10:18:19 2024 +0800

    wifi: ath12k: fix invalid AMPDU factor calculation in ath12k_peer_assoc_h_he()
    
    [ Upstream commit a66de2d0f22b1740f3f9777776ad98c4bee62dff ]
    
    Currently ampdu_factor is wrongly calculated in ath12k_peer_assoc_h_he(), fix it.
    
    This is found during code review.
    
    Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: Baochen Qiang <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath12k: match WMI BSS chan info structure with firmware definition [+ + +]
Author: P Praneesh <[email protected]>
Date:   Mon Apr 1 00:02:32 2024 +0530

    wifi: ath12k: match WMI BSS chan info structure with firmware definition
    
    [ Upstream commit dd98d54db29fb553839f43ade5f547baa93392c8 ]
    
    struct wmi_pdev_bss_chan_info_event is not similar to the firmware
    struct definition, this will cause some random failures.
    
    Fix by matching the struct wmi_pdev_bss_chan_info_event with the
    firmware structure definition.
    
    Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
    
    Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
    Signed-off-by: P Praneesh <[email protected]>
    Signed-off-by: Karthikeyan Kathirvel <[email protected]>
    Acked-by: Jeff Johnson <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: ath9k: Remove error checks when creating debugfs entries [+ + +]
Author: Toke Høiland-Jørgensen <[email protected]>
Date:   Mon Aug 5 13:02:22 2024 +0200

    wifi: ath9k: Remove error checks when creating debugfs entries
    
    [ Upstream commit f6ffe7f0184792c2f99aca6ae5b916683973d7d3 ]
    
    We should not be checking the return values from debugfs creation at all: the
    debugfs functions are designed to handle errors of previously called functions
    and just transparently abort the creation of debugfs entries when debugfs is
    disabled. If we check the return value and abort driver initialisation, we break
    the driver if debugfs is disabled (such as when booting with debugfs=off).
    
    Earlier versions of ath9k accidentally did the right thing by checking the
    return value, but only for NULL, not for IS_ERR(). This was "fixed" by the two
    commits referenced below, breaking ath9k with debugfs=off starting from the 6.6
    kernel (as reported in the Bugzilla linked below).
    
    Restore functionality by just getting rid of the return value check entirely.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219122
    Fixes: 1e4134610d93 ("wifi: ath9k: use IS_ERR() with debugfs_create_dir()")
    Fixes: 6edb4ba6fb5b ("wifi: ath9k: fix parameter check in ath9k_init_debug()")
    Reported-by: Daniel Tobias <[email protected]>
    Tested-by: Daniel Tobias <[email protected]>
    Signed-off-by: Toke Høiland-Jørgensen <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: brcmfmac: add linefeed at end of file [+ + +]
Author: Arend van Spriel <[email protected]>
Date:   Sun Jan 28 10:30:56 2024 +0100

    wifi: brcmfmac: add linefeed at end of file
    
    commit 26f0dc8a705ae182eaa126cef0a9870d1a87a5ac upstream.
    
    The following sparse warning was reported:
    
    drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49:
      warning: no newline at end of file
    
    Fixes: 31343230abb1 ("wifi: brcmfmac: export firmware interface functions")
    Reported-by: Jakub Kicinski <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: brcmfmac: export firmware interface functions [+ + +]
Author: Arend van Spriel <[email protected]>
Date:   Wed Jan 3 10:57:01 2024 +0100

    wifi: brcmfmac: export firmware interface functions
    
    [ Upstream commit 31343230abb1683e8afb254e6b13a7a7fd01fcac ]
    
    With multi-vendor support the vendor-specific module may need to use
    the firmware interface functions so export them using the macro
    BRCMF_EXPORT_SYMBOL_GPL() which exports them to driver namespace.
    
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://msgid.link/[email protected]
    Stable-dep-of: c6002b6c05f3 ("wifi: brcmfmac: introducing fwil query functions")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: brcmfmac: introducing fwil query functions [+ + +]
Author: Arend van Spriel <[email protected]>
Date:   Sat Jul 27 20:56:17 2024 +0200

    wifi: brcmfmac: introducing fwil query functions
    
    [ Upstream commit c6002b6c05f3edfa12fd25990cc637281f200442 ]
    
    When the firmware interface layer was refactored it provided various
    "get" and "set" functions. For the "get" in some cases a parameter
    needed to be passed down to firmware as a key indicating what to
    "get" turning the output parameter of the "get" function into an
    input parameter as well. To accommodate this the "get" function blindly
    copies the parameter which in some places resulted in an uninitialized
    warnings from the compiler. These have been fixed by initializing the
    input parameter in the past. Recently another batch of similar fixes
    were submitted to address clang static checker warnings [1].
    
    Proposing another solution by introducing a "query" variant which is used
    when the (input) parameter is needed by firmware. The "get" variant will
    only fill the (output) parameter with the result received from firmware
    taking care of proper endianess conversion.
    
    [1] https://lore.kernel.org/all/[email protected]/
    
    Fixes: 81f5dcb80830 ("brcmfmac: refactor firmware interface layer.")
    Reported-by: Su Hui <[email protected]>
    Signed-off-by: Arend van Spriel <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Mon Sep 9 12:08:06 2024 +0300

    wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors
    
    [ Upstream commit 15ea13b1b1fbf6364d4cd568e65e4c8479632999 ]
    
    Although not reproduced in practice, these two cases may be
    considered by UBSAN as off-by-one errors. So fix them in the
    same way as in commit a26a5107bc52 ("wifi: cfg80211: fix UBSAN
    noise in cfg80211_wext_siwscan()").
    
    Fixes: 807f8a8c3004 ("cfg80211/nl80211: add support for scheduled scans")
    Fixes: 5ba63533bbf6 ("cfg80211: fix alignment problem in scan request")
    Signed-off-by: Dmitry Antipov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan() [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Thu Sep 5 18:04:00 2024 +0300

    wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()
    
    [ Upstream commit a26a5107bc52922cf5f67361e307ad66547b51c7 ]
    
    Looking at https://syzkaller.appspot.com/bug?extid=1a3986bbd3169c307819
    and running reproducer with CONFIG_UBSAN_BOUNDS, I've noticed the
    following:
    
    [ T4985] UBSAN: array-index-out-of-bounds in net/wireless/scan.c:3479:25
    [ T4985] index 164 is out of range for type 'struct ieee80211_channel *[]'
    <...skipped...>
    [ T4985] Call Trace:
    [ T4985]  <TASK>
    [ T4985]  dump_stack_lvl+0x1c2/0x2a0
    [ T4985]  ? __pfx_dump_stack_lvl+0x10/0x10
    [ T4985]  ? __pfx__printk+0x10/0x10
    [ T4985]  __ubsan_handle_out_of_bounds+0x127/0x150
    [ T4985]  cfg80211_wext_siwscan+0x11a4/0x1260
    <...the rest is not too useful...>
    
    Even if we do 'creq->n_channels = n_channels' before 'creq->ssids =
    (void *)&creq->channels[n_channels]', UBSAN treats the latter as
    off-by-one error. Fix this by using pointer arithmetic rather than
    an expression with explicit array indexing and use convenient
    'struct_size()' to simplify the math here and in 'kzalloc()' above.
    
    Fixes: 5ba63533bbf6 ("cfg80211: fix alignment problem in scan request")
    Signed-off-by: Dmitry Antipov <[email protected]>
    Reviewed-by: Kees Cook <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [fix coding style for multi-line calculation]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: config: label 'gl' devices as discrete [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Jul 29 20:20:07 2024 +0300

    wifi: iwlwifi: config: label 'gl' devices as discrete
    
    [ Upstream commit 8131dd52810dfcdb49fcdc78f5e18e1538b6c441 ]
    
    The 'gl' devices are in the bz family, but they're not,
    integrated, so should have their own trans config struct.
    Fix that, also necessitating the removal of LTR config,
    and while at it remove 0x2727 and 0x272D IDs that were
    only used for test chips.
    
    Fixes: c30a2a64788b ("wifi: iwlwifi: add a new PCI device ID for BZ device")ticket=none
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://patch.msgid.link/20240729201718.95aed0620080.Ib9129512c95aa57acc9876bdff8b99dd41e1562c@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: mvm: increase the time between ranging measurements [+ + +]
Author: Avraham Stern <[email protected]>
Date:   Mon Jul 29 20:20:12 2024 +0300

    wifi: iwlwifi: mvm: increase the time between ranging measurements
    
    [ Upstream commit 3a7ee94559dfd640604d0265739e86dec73b64e8 ]
    
    The algo running in fw may take a little longer than 5 milliseconds,
    (e.g. measurement on 80MHz while associated). Increase the minimum
    time between measurements to 7 milliseconds.
    
    Fixes: 830aa3e7d1ca ("iwlwifi: mvm: add support for range request command version 13")
    Signed-off-by: Avraham Stern <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://patch.msgid.link/20240729201718.d3f3c26e00d9.I09e951290e8a3d73f147b88166fd9a678d1d69ed@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: iwlwifi: remove AX101, AX201 and AX203 support from LNL [+ + +]
Author: Golan Ben Ami <[email protected]>
Date:   Thu Jun 13 17:11:23 2024 +0300

    wifi: iwlwifi: remove AX101, AX201 and AX203 support from LNL
    
    [ Upstream commit 6adae0b081454393ca5f7363fd3c7379c8e2a7a1 ]
    
    LNL is the codename for the upcoming Series 2 Core Ultra
    processors designed by Intel. AX101, AX201 and AX203 devices
    are not shiped on LNL platforms, so don't support them.
    
    Signed-off-by: Golan Ben Ami <[email protected]>
    Signed-off-by: Miri Korenblit <[email protected]>
    Link: https://patch.msgid.link/20240613171043.f24a228dfd96.I989a2d3f1513211bc49ac8143ee4e9e341e1ee67@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Stable-dep-of: 8131dd52810d ("wifi: iwlwifi: config: label 'gl' devices as discrete")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: don't use rate mask for offchannel TX either [+ + +]
Author: Ping-Ke Shih <[email protected]>
Date:   Mon Jul 29 15:48:16 2024 +0800

    wifi: mac80211: don't use rate mask for offchannel TX either
    
    [ Upstream commit e7a7ef9a0742dbd0818d5b15fba2c5313ace765b ]
    
    Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for
    scanning"), ignore incorrect settings to avoid no supported rate warning
    reported by syzbot.
    
    The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:
    fix default HE tx bitrate mask in 2G band"), which however corrects
    bitmask of HE MCS and recognizes correctly settings of empty legacy rate
    plus HE MCS rate instead of returning -EINVAL.
    
    As suggestions [1], follow the change of SCAN TX to consider this case of
    offchannel TX as well.
    
    [1] https://lore.kernel.org/linux-wireless/[email protected]/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024
    
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/linux-wireless/[email protected]/
    Fixes: 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band")
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Fri Sep 6 15:31:51 2024 +0300

    wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()
    
    [ Upstream commit 9d301de12da6e1bb069a9835c38359b8e8135121 ]
    
    Since '__dev_queue_xmit()' should be called with interrupts enabled,
    the following backtrace:
    
    ieee80211_do_stop()
     ...
     spin_lock_irqsave(&local->queue_stop_reason_lock, flags)
     ...
     ieee80211_free_txskb()
      ieee80211_report_used_skb()
       ieee80211_report_ack_skb()
        cfg80211_mgmt_tx_status_ext()
         nl80211_frame_tx_status()
          genlmsg_multicast_netns()
           genlmsg_multicast_netns_filtered()
            nlmsg_multicast_filtered()
             netlink_broadcast_filtered()
              do_one_broadcast()
               netlink_broadcast_deliver()
                __netlink_sendskb()
                 netlink_deliver_tap()
                  __netlink_deliver_tap_skb()
                   dev_queue_xmit()
                    __dev_queue_xmit() ; with IRQS disabled
     ...
     spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)
    
    issues the warning (as reported by syzbot reproducer):
    
    WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120
    
    Fix this by implementing a two-phase skb reclamation in
    'ieee80211_do_stop()', where actual work is performed
    outside of a section with interrupts disabled.
    
    Fixes: 5061b0c2b906 ("mac80211: cooperate more with network namespaces")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=1a3986bbd3169c307819
    Signed-off-by: Dmitry Antipov <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7603: fix mixed declarations and code [+ + +]
Author: Felix Fietkau <[email protected]>
Date:   Tue Aug 27 11:29:48 2024 +0200

    wifi: mt76: mt7603: fix mixed declarations and code
    
    [ Upstream commit 9b8d932053b8b45d650360b36f701cf0f9b6470e ]
    
    Move the qid variable declaration further up
    
    Fixes: b473c0e47f04 ("wifi: mt76: mt7603: fix tx queue of loopback packets")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7615: check devm_kasprintf() returned value [+ + +]
Author: Ma Ke <[email protected]>
Date:   Thu Sep 5 09:47:53 2024 +0800

    wifi: mt76: mt7615: check devm_kasprintf() returned value
    
    commit 5acdc432f832d810e0d638164c393b877291d9b4 upstream.
    
    devm_kasprintf() can return a NULL pointer on failure but this returned
    value is not checked. Fix this lack and check the returned value.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 0bb4e9187ea4 ("mt76: mt7615: fix hwmon temp sensor mem use-after-free")
    Signed-off-by: Ma Ke <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: mt7915: check devm_kasprintf() returned value [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Sep 3 09:49:55 2024 +0800

    wifi: mt76: mt7915: check devm_kasprintf() returned value
    
    commit 267efeda8c55f30e0e7c5b7fd03dea4efec6916c upstream.
    
    devm_kasprintf() can return a NULL pointer on failure but this returned
    value is not checked. Fix this lack and check the returned value.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 6ae39b7c7ed4 ("wifi: mt76: mt7921: Support temp sensor")
    Signed-off-by: Ma Ke <[email protected]>
    Reviewed-by: Matthias Brugger <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: mt7915: fix oops on non-dbdc mt7986 [+ + +]
Author: Bjørn Mork <[email protected]>
Date:   Sat Jul 13 15:00:10 2024 +0200

    wifi: mt76: mt7915: fix oops on non-dbdc mt7986
    
    [ Upstream commit 862bf7cbd772c2bad570ef0c5b5556a1330656dd ]
    
    mt7915_band_config() sets band_idx = 1 on the main phy for mt7986
    with MT7975_ONE_ADIE or MT7976_ONE_ADIE.
    
    Commit 0335c034e726 ("wifi: mt76: fix race condition related to
    checking tx queue fill status") introduced a dereference of the
    phys array indirectly indexed by band_idx via wcid->phy_idx in
    mt76_wcid_cleanup(). This caused the following Oops on affected
    mt7986 devices:
    
     Unable to handle kernel read from unreadable memory at virtual address 0000000000000024
     Mem abort info:
       ESR = 0x0000000096000005
       EC = 0x25: DABT (current EL), IL = 32 bits
       SET = 0, FnV = 0
       EA = 0, S1PTW = 0
       FSC = 0x05: level 1 translation fault
     Data abort info:
       ISV = 0, ISS = 0x00000005
       CM = 0, WnR = 0
     user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000
     [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
     Internal error: Oops: 0000000096000005 [#1] SMP
     Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...
     CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0
     Hardware name: ZyXEL EX5700 (Telenor) (DT)
     pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : mt76_wcid_cleanup+0x84/0x22c [mt76]
     lr : mt76_wcid_cleanup+0x64/0x22c [mt76]
     sp : ffffffc00a803700
     x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00
     x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001
     x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8
     x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000
     x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0
     x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000
     x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28
     x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000
     x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001
     x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024
     Call trace:
      mt76_wcid_cleanup+0x84/0x22c [mt76]
      __mt76_sta_remove+0x70/0xbc [mt76]
      mt76_sta_state+0x8c/0x1a4 [mt76]
      mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]
      drv_sta_state+0x144/0x274 [mac80211]
      sta_info_move_state+0x1cc/0x2a4 [mac80211]
      sta_set_sinfo+0xaf8/0xc24 [mac80211]
      sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]
    
      ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]
      cfg80211_check_station_change+0x1360/0x4710 [cfg80211]
      genl_family_rcv_msg_doit+0xb4/0x110
      genl_rcv_msg+0xd0/0x1bc
      netlink_rcv_skb+0x58/0x120
      genl_rcv+0x34/0x50
      netlink_unicast+0x1f0/0x2ec
      netlink_sendmsg+0x198/0x3d0
      ____sys_sendmsg+0x1b0/0x210
      ___sys_sendmsg+0x80/0xf0
      __sys_sendmsg+0x44/0xa0
      __arm64_sys_sendmsg+0x20/0x30
      invoke_syscall.constprop.0+0x4c/0xe0
      do_el0_svc+0x40/0xd0
      el0_svc+0x14/0x4c
      el0t_64_sync_handler+0x100/0x110
      el0t_64_sync+0x15c/0x160
     Code: d2800002 910092c0 52800023 f9800011 (885f7c01)
     ---[ end trace 7e42dd9a39ed2281 ]---
    
    Fix by using mt76_dev_phy() which will map band_idx to the correct phy
    for all hardware combinations.
    
    Fixes: 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status")
    Link: https://github.com/openwrt/openwrt/issues/14548
    Signed-off-by: Bjørn Mork <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7915: fix rx filter setting for bfee functionality [+ + +]
Author: Howard Hsu <[email protected]>
Date:   Tue Aug 27 11:30:08 2024 +0200

    wifi: mt76: mt7915: fix rx filter setting for bfee functionality
    
    [ Upstream commit 6ac80fce713e875a316a58975b830720a3e27721 ]
    
    Fix rx filter setting to prevent dropping NDPA frames. Without this
    change, bfee functionality may behave abnormally.
    
    Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
    Signed-off-by: Howard Hsu <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7921: Check devm_kasprintf() returned value [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Sep 3 09:44:55 2024 +0800

    wifi: mt76: mt7921: Check devm_kasprintf() returned value
    
    commit 1ccc9e476ce76e8577ba4fdbd1f63cb3e3499d38 upstream.
    
    devm_kasprintf() can return a NULL pointer on failure but this returned
    value is not checked. Fix this lack and check the returned value.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 6ae39b7c7ed4 ("wifi: mt76: mt7921: Support temp sensor")
    Signed-off-by: Ma Ke <[email protected]>
    Reviwed-by: Matthias Brugger <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: mt7996: ensure 4-byte alignment for beacon commands [+ + +]
Author: Benjamin Lin <[email protected]>
Date:   Fri Jan 26 17:09:16 2024 +0800

    wifi: mt76: mt7996: ensure 4-byte alignment for beacon commands
    
    [ Upstream commit 5d197d37809b220616a0fb00856b9eeeafe1f69e ]
    
    If TLV includes beacon content, its length might not be 4-byte aligned.
    Make sure the length is aligned before sending beacon commands to FW.
    
    Signed-off-by: Benjamin Lin <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Signed-off-by: Felix Fietkau <[email protected]>
    Stable-dep-of: 9e461f4a2329 ("wifi: mt76: mt7996: fix uninitialized TLV data")
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix EHT beamforming capability check [+ + +]
Author: Howard Hsu <[email protected]>
Date:   Fri Aug 16 17:46:31 2024 +0800

    wifi: mt76: mt7996: fix EHT beamforming capability check
    
    [ Upstream commit 9ca65757f0a5b393a7737d37f377d5daf91716af ]
    
    If a VIF acts as a beamformer, it should check peer's beamformee
    capability, and vice versa.
    
    Fixes: ba01944adee9 ("wifi: mt76: mt7996: add EHT beamforming support")
    Signed-off-by: Howard Hsu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix HE and EHT beamforming capabilities [+ + +]
Author: Howard Hsu <[email protected]>
Date:   Fri Aug 16 17:46:29 2024 +0800

    wifi: mt76: mt7996: fix HE and EHT beamforming capabilities
    
    [ Upstream commit e1f4847fdbdf5d44ae60e035c131920e5ab88598 ]
    
    Fix HE and EHT beamforming capabilities for different bands and
    interface types.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init")
    Signed-off-by: Howard Hsu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he [+ + +]
Author: Ma Ke <[email protected]>
Date:   Tue Aug 13 16:12:42 2024 +0800

    wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he
    
    commit f503ae90c7355e8506e68498fe84c1357894cd5b upstream.
    
    Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he
    routine adding an sta interface to the mt7996 driver.
    
    Found by code review.
    
    Cc: [email protected]
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Ma Ke <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: mt76: mt7996: fix traffic delay when switching back to working channel [+ + +]
Author: Peter Chiu <[email protected]>
Date:   Fri Aug 16 17:46:26 2024 +0800

    wifi: mt76: mt7996: fix traffic delay when switching back to working channel
    
    [ Upstream commit 376200f095d0c3a7096199b336204698d7086279 ]
    
    During scanning, UNI_CHANNEL_RX_PATH tag is necessary for the firmware to
    properly stop and resume MAC TX queue. Without this tag, HW needs more time
    to resume traffic when switching back to working channel.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix uninitialized TLV data [+ + +]
Author: Felix Fietkau <[email protected]>
Date:   Tue Aug 27 11:30:10 2024 +0200

    wifi: mt76: mt7996: fix uninitialized TLV data
    
    [ Upstream commit 9e461f4a2329109571f4b10f9bcad28d07e6ebb3 ]
    
    Use skb_put_zero instead of skb_put
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: fix wmm set of station interface to 3 [+ + +]
Author: Peter Chiu <[email protected]>
Date:   Fri Aug 16 17:46:27 2024 +0800

    wifi: mt76: mt7996: fix wmm set of station interface to 3
    
    [ Upstream commit 9265397caacf5c0c2d10c40b2958a474664ebd9e ]
    
    According to connac3 HW design, the WMM index of AP and STA interface
    should be 0 and 3, respectively.
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mt76: mt7996: use hweight16 to get correct tx antenna [+ + +]
Author: Peter Chiu <[email protected]>
Date:   Fri Aug 16 17:46:25 2024 +0800

    wifi: mt76: mt7996: use hweight16 to get correct tx antenna
    
    [ Upstream commit f98c3de92bb05dac4a4969df8a4595ed380b4604 ]
    
    The chainmask is u16 so using hweight8 cannot get correct tx_ant.
    Without this patch, the tx_ant of band 2 would be -1 and lead to the
    following issue:
    BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]
    
    Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
    Signed-off-by: Peter Chiu <[email protected]>
    Signed-off-by: Shayne Chen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Felix Fietkau <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c [+ + +]
Author: Nick Morrow <[email protected]>
Date:   Thu Jul 11 01:14:23 2024 +0300

    wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c
    
    commit 0af8cd2822f31ed8363223329e5cff2a7ed01961 upstream.
    
    Remove VID/PID 0bda:c82c as it was inadvertently added to the device
    list in driver rtw8821cu. This VID/PID is for the rtw8822cu device
    and it is already in the appropriate place for that device.
    
    Cc: [email protected]
    Signed-off-by: Nick Morrow <[email protected]>
    Signed-off-by: Bitterblue Smith <[email protected]>
    Acked-by: Ping-Ke Shih <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtw88: 8822c: Fix reported RX band width [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Tue Jul 23 22:31:36 2024 +0300

    wifi: rtw88: 8822c: Fix reported RX band width
    
    commit a71ed5898dfae68262f79277915d1dfe34586bc6 upstream.
    
    "iw dev wlp2s0 station dump" shows incorrect rx bitrate:
    
    tx bitrate:     866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
    rx bitrate:     86.7 MBit/s VHT-MCS 9 VHT-NSS 1
    
    This is because the RX band width is calculated incorrectly. Fix the
    calculation according to the phydm_rxsc_2_bw() function from the
    official drivers.
    
    After:
    
    tx bitrate:     866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
    rx bitrate:     390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1
    
    It also works correctly with the AP configured for 20 MHz and 40 MHz.
    
    Tested with RTL8822CE.
    
    Cc: [email protected]
    Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
    Signed-off-by: Bitterblue Smith <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtw88: always wait for both firmware loading attempts [+ + +]
Author: Dmitry Antipov <[email protected]>
Date:   Fri Jul 26 14:46:57 2024 +0300

    wifi: rtw88: always wait for both firmware loading attempts
    
    [ Upstream commit 0e735a4c6137262bcefe45bb52fde7b1f5fc6c4d ]
    
    In 'rtw_wait_firmware_completion()', always wait for both (regular and
    wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'
    has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue
    'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually
    the wowlan one) is still in progress, causing UAF detected by KASAN.
    
    Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3
    Signed-off-by: Dmitry Antipov <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: rtw88: Fix USB/SDIO devices not transmitting beacons [+ + +]
Author: Bitterblue Smith <[email protected]>
Date:   Wed Aug 21 16:11:03 2024 +0300

    wifi: rtw88: Fix USB/SDIO devices not transmitting beacons
    
    commit faa2e484b393c56bc1243dca6676a70bc485f775 upstream.
    
    All USB devices supported by rtw88 have the same problem: they don't
    transmit beacons in AP mode. (Some?) SDIO devices are also affected.
    The cause appears to be clearing BIT_EN_BCNQ_DL of REG_FWHW_TXQ_CTRL
    before uploading the beacon reserved page, so don't clear the bit for
    USB and SDIO devices.
    
    Tested with RTL8811CU and RTL8723DU.
    
    Cc: <[email protected]> # 6.6.x
    Signed-off-by: Bitterblue Smith <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

wifi: rtw88: remove CPT execution branch never used [+ + +]
Author: Dmitry Kandybka <[email protected]>
Date:   Fri Aug 9 11:53:10 2024 +0300

    wifi: rtw88: remove CPT execution branch never used
    
    [ Upstream commit 77c977327dfaa9ae2e154964cdb89ceb5c7b7cf1 ]
    
    In 'rtw_coex_action_bt_a2dp_pan', 'wl_cpt_test' and 'bt_cpt_test' are
    hardcoded to false, so corresponding 'table_case' and 'tdma_case'
    assignments are never met.
    Also 'rtw_coex_set_rf_para(rtwdev, chip->wl_rf_para_rx[1])' is never
    executed. Assuming that CPT was never fully implemented, remove
    lookalike leftovers. Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 76f631cb401f ("rtw88: coex: update the mechanism for A2DP + PAN")
    
    Signed-off-by: Dmitry Kandybka <[email protected]>
    Signed-off-by: Ping-Ke Shih <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param [+ + +]
Author: Jiawei Ye <[email protected]>
Date:   Thu Aug 29 08:17:09 2024 +0000

    wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param
    
    [ Upstream commit 6d7c6ae1efb1ff68bc01d79d94fdf0388f86cdd8 ]
    
    In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`
    structure is accessed after the RCU read-side critical section is
    unlocked. According to RCU usage rules, this is illegal. Reusing this
    pointer can lead to unpredictable behavior, including accessing memory
    that has been updated or causing use-after-free issues.
    
    This possible bug was identified using a static analysis tool developed
    by myself, specifically designed to detect RCU-related issues.
    
    To address this, the TSF value is now stored in a local variable
    `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is
    then assigned using this local variable, ensuring that the TSF value is
    safely accessed.
    
    Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path")
    Signed-off-by: Jiawei Ye <[email protected]>
    Reviewed-by: Alexis Lothoré <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/entry: Remove unwanted instrumentation in common_interrupt() [+ + +]
Author: Dmitry Vyukov <[email protected]>
Date:   Tue Jun 11 09:50:30 2024 +0200

    x86/entry: Remove unwanted instrumentation in common_interrupt()
    
    [ Upstream commit 477d81a1c47a1b79b9c08fc92b5dea3c5143800b ]
    
    common_interrupt() and related variants call kvm_set_cpu_l1tf_flush_l1d(),
    which is neither marked noinstr nor __always_inline.
    
    So compiler puts it out of line and adds instrumentation to it.  Since the
    call is inside of instrumentation_begin/end(), objtool does not warn about
    it.
    
    The manifestation is that KCOV produces spurious coverage in
    kvm_set_cpu_l1tf_flush_l1d() in random places because the call happens when
    preempt count is not yet updated to say that the kernel is in an interrupt.
    
    Mark kvm_set_cpu_l1tf_flush_l1d() as __always_inline and move it out of the
    instrumentation_begin/end() section.  It only calls __this_cpu_write()
    which is already safe to call in noinstr contexts.
    
    Fixes: 6368558c3710 ("x86/entry: Provide IDTENTRY_SYSVEC")
    Signed-off-by: Dmitry Vyukov <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Alexander Potapenko <[email protected]>
    Acked-by: Peter Zijlstra (Intel) <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/3f9a1de9e415fcb53d07dc9e19fa8481bb021b1b.1718092070.git.dvyukov@google.com
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/idtentry: Incorporate definitions/declarations of the FRED entries [+ + +]
Author: Xin Li <[email protected]>
Date:   Tue Dec 5 02:50:11 2023 -0800

    x86/idtentry: Incorporate definitions/declarations of the FRED entries
    
    [ Upstream commit 90f357208200a941e90e75757123326684d715d0 ]
    
    FRED and IDT can share most of the definitions and declarations so
    that in the majority of cases the actual handler implementation is the
    same.
    
    The differences are the exceptions where FRED stores exception related
    information on the stack and the sysvec implementations as FRED can
    handle irqentry/exit() in the dispatcher instead of having it in each
    handler.
    
    Also add stub defines for vectors which are not used due to Kconfig
    decisions to spare the ifdeffery in the actual FRED dispatch code.
    
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Xin Li <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Tested-by: Shan Kang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: 477d81a1c47a ("x86/entry: Remove unwanted instrumentation in common_interrupt()")
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/mm: Use IPIs to synchronize LAM enablement [+ + +]
Author: Yosry Ahmed <[email protected]>
Date:   Tue Jul 2 13:21:37 2024 +0000

    x86/mm: Use IPIs to synchronize LAM enablement
    
    [ Upstream commit 3b299b99556c1753923f8d9bbd9304bcd139282f ]
    
    LAM can only be enabled when a process is single-threaded.  But _kernel_
    threads can temporarily use a single-threaded process's mm.
    
    If LAM is enabled by a userspace process while a kthread is using its
    mm, the kthread will not observe LAM enablement (i.e.  LAM will be
    disabled in CR3). This could be fine for the kthread itself, as LAM only
    affects userspace addresses. However, if the kthread context switches to
    a thread in the same userspace process, CR3 may or may not be updated
    because the mm_struct doesn't change (based on pending TLB flushes). If
    CR3 is not updated, the userspace thread will run incorrectly with LAM
    disabled, which may cause page faults when using tagged addresses.
    Example scenario:
    
    CPU 1                                   CPU 2
    /* kthread */
    kthread_use_mm()
                                            /* user thread */
                                            prctl_enable_tagged_addr()
                                            /* LAM enabled on CPU 2 */
    /* LAM disabled on CPU 1 */
                                            context_switch() /* to CPU 1 */
    /* Switching to user thread */
    switch_mm_irqs_off()
    /* CR3 not updated */
    /* LAM is still disabled on CPU 1 */
    
    Synchronize LAM enablement by sending an IPI to all CPUs running with
    the mm_struct to enable LAM. This makes sure LAM is enabled on CPU 1
    in the above scenario before prctl_enable_tagged_addr() returns and
    userspace starts using tagged addresses, and before it's possible to
    run the userspace process on CPU 1.
    
    In switch_mm_irqs_off(), move reading the LAM mask until after
    mm_cpumask() is updated. This ensures that if an outdated LAM mask is
    written to CR3, an IPI is received to update it right after IRQs are
    re-enabled.
    
    [ dhansen: Add a LAM enabling helper and comment it ]
    
    Fixes: 82721d8b25d7 ("x86/mm: Handle LAM on context switch")
    Suggested-by: Andy Lutomirski <[email protected]>
    Signed-off-by: Yosry Ahmed <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Kirill A. Shutemov <[email protected]>
    Link: https://lore.kernel.org/all/20240702132139.3332013-2-yosryahmed%40google.com
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/PCI: Check pcie_find_root_port() return for NULL [+ + +]
Author: Samasth Norway Ananda <[email protected]>
Date:   Mon Aug 12 13:26:59 2024 -0700

    x86/PCI: Check pcie_find_root_port() return for NULL
    
    [ Upstream commit dbc3171194403d0d40e4bdeae666f6e76e428b53 ]
    
    If pcie_find_root_port() is unable to locate a Root Port, it will return
    NULL. Check the pointer for NULL before dereferencing it.
    
    This particular case is in a quirk for devices that are always below a Root
    Port, so this won't avoid a problem and doesn't need to be backported, but
    check as a matter of style and to prevent copy/paste mistakes.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Samasth Norway Ananda <[email protected]>
    [bhelgaas: drop Fixes: and explain why there's no problem in this case]
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Mario Limonciello <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/sgx: Fix deadlock in SGX NUMA node search [+ + +]
Author: Aaron Lu <[email protected]>
Date:   Thu Sep 5 16:08:54 2024 +0800

    x86/sgx: Fix deadlock in SGX NUMA node search
    
    [ Upstream commit 9c936844010466535bd46ea4ce4656ef17653644 ]
    
    When the current node doesn't have an EPC section configured by firmware
    and all other EPC sections are used up, CPU can get stuck inside the
    while loop that looks for an available EPC page from remote nodes
    indefinitely, leading to a soft lockup. Note how nid_of_current will
    never be equal to nid in that while loop because nid_of_current is not
    set in sgx_numa_mask.
    
    Also worth mentioning is that it's perfectly fine for the firmware not
    to setup an EPC section on a node. While setting up an EPC section on
    each node can enhance performance, it is not a requirement for
    functionality.
    
    Rework the loop to start and end on *a* node that has SGX memory. This
    avoids the deadlock looking for the current SGX-lacking node to show up
    in the loop when it never will.
    
    Fixes: 901ddbb9ecf5 ("x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()")
    Reported-by: "Molina Sabido, Gerardo" <[email protected]>
    Signed-off-by: Aaron Lu <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Kai Huang <[email protected]>
    Reviewed-by: Jarkko Sakkinen <[email protected]>
    Acked-by: Dave Hansen <[email protected]>
    Tested-by: Zhimin Luo <[email protected]>
    Link: https://lore.kernel.org/all/20240905080855.1699814-2-aaron.lu%40intel.com
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/tdx: Fix "in-kernel MMIO" check [+ + +]
Author: Alexey Gladkov (Intel) <[email protected]>
Date:   Fri Sep 13 19:05:56 2024 +0200

    x86/tdx: Fix "in-kernel MMIO" check
    
    commit d4fc4d01471528da8a9797a065982e05090e1d81 upstream.
    
    TDX only supports kernel-initiated MMIO operations. The handle_mmio()
    function checks if the #VE exception occurred in the kernel and rejects
    the operation if it did not.
    
    However, userspace can deceive the kernel into performing MMIO on its
    behalf. For example, if userspace can point a syscall to an MMIO address,
    syscall does get_user() or put_user() on it, triggering MMIO #VE. The
    kernel will treat the #VE as in-kernel MMIO.
    
    Ensure that the target MMIO address is within the kernel before decoding
    instruction.
    
    Fixes: 31d58c4e557d ("x86/tdx: Handle in-kernel MMIO")
    Signed-off-by: Alexey Gladkov (Intel) <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Kirill A. Shutemov <[email protected]>
    Acked-by: Dave Hansen <[email protected]>
    Cc:[email protected]
    Link: https://lore.kernel.org/all/565a804b80387970460a4ebc67c88d1380f61ad1.1726237595.git.legion%40kernel.org
    Signed-off-by: Alexey Gladkov (Intel) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xen/swiotlb: add alignment check for dma buffers [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Fri Sep 13 12:05:02 2024 +0200

    xen/swiotlb: add alignment check for dma buffers
    
    [ Upstream commit 9f40ec84a7976d95c34e7cc070939deb103652b0 ]
    
    When checking a memory buffer to be consecutive in machine memory,
    the alignment needs to be checked, too. Failing to do so might result
    in DMA memory not being aligned according to its requested size,
    leading to error messages like:
    
      4xxx 0000:2b:00.0: enabling device (0140 -> 0142)
      4xxx 0000:2b:00.0: Ring address not aligned
      4xxx 0000:2b:00.0: Failed to initialise service qat_crypto
      4xxx 0000:2b:00.0: Resetting device qat_dev0
      4xxx: probe of 0000:2b:00.0 failed with error -14
    
    Fixes: 9435cce87950 ("xen/swiotlb: Add support for 64KB page granularity")
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Stefano Stabellini <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

xen/swiotlb: fix allocated size [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Sun Sep 15 13:06:44 2024 +0200

    xen/swiotlb: fix allocated size
    
    [ Upstream commit c3dea3d54f4d399f8044547f0f1abdccbdfb0fee ]
    
    The allocated size in xen_swiotlb_alloc_coherent() and
    xen_swiotlb_free_coherent() is calculated wrong for the case of
    XEN_PAGE_SIZE not matching PAGE_SIZE. Fix that.
    
    Fixes: 7250f422da04 ("xen-swiotlb: use actually allocated size on check physical continuous")
    Reported-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Reviewed-by: Stefano Stabellini <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xen: add capability to remap non-RAM pages to different PFNs [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Wed Aug 14 16:47:25 2024 +0200

    xen: add capability to remap non-RAM pages to different PFNs
    
    [ Upstream commit d05208cf7f05420ad10cc7f9550f91d485523659 ]
    
    When running as a Xen PV dom0 it can happen that the kernel is being
    loaded to a guest physical address conflicting with the host memory
    map.
    
    In order to be able to resolve this conflict, add the capability to
    remap non-RAM areas to different guest PFNs. A function to use this
    remapping information for other purposes than doing the remap will be
    added when needed.
    
    As the number of conflicts should be rather low (currently only
    machines with max. 1 conflict are known), save the remap data in a
    small statically allocated array.
    
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Stable-dep-of: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory")
    Signed-off-by: Sasha Levin <[email protected]>

xen: allow mapping ACPI data using a different physical address [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Fri Aug 9 17:52:55 2024 +0200

    xen: allow mapping ACPI data using a different physical address
    
    commit 9221222c717dbddac1e3c49906525475d87a3a44 upstream.
    
    When running as a Xen PV dom0 the system needs to map ACPI data of the
    host using host physical addresses, while those addresses can conflict
    with the guest physical addresses of the loaded linux kernel. The same
    problem might apply in case a PV guest is configured to use the host
    memory map.
    
    This conflict can be solved by mapping the ACPI data to a different
    guest physical address, but mapping the data via acpi_os_ioremap()
    must still be possible using the host physical address, as this
    address might be generated by AML when referencing some of the ACPI
    data.
    
    When configured to support running as a Xen PV domain, have an
    implementation of acpi_os_ioremap() being aware of the possibility to
    need above mentioned translation of a host physical address to the
    guest physical address.
    
    This modification requires to #include linux/acpi.h in some sources
    which need to include asm/acpi.h directly.
    
    Signed-off-by: Juergen Gross <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

xen: introduce generic helper checking for memory map conflicts [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Fri Aug 2 14:11:06 2024 +0200

    xen: introduce generic helper checking for memory map conflicts
    
    [ Upstream commit ba88829706e2c5b7238638fc2b0713edf596495e ]
    
    When booting as a Xen PV dom0 the memory layout of the dom0 is
    modified to match that of the host, as this requires less changes in
    the kernel for supporting Xen.
    
    There are some cases, though, which are problematic, as it is the Xen
    hypervisor selecting the kernel's load address plus some other data,
    which might conflict with the host's memory map.
    
    These conflicts are detected at boot time and result in a boot error.
    In order to support handling at least some of these conflicts in
    future, introduce a generic helper function which will later gain the
    ability to adapt the memory layout when possible.
    
    Add the missing check for the xen_start_info area.
    
    Note that possible p2m map and initrd memory conflicts are handled
    already by copying the data to memory areas not conflicting with the
    memory map. The initial stack allocated by Xen doesn't need to be
    checked, as early boot code is switching to the statically allocated
    initial kernel stack. Initial page tables and the kernel itself will
    be handled later.
    
    Signed-off-by: Juergen Gross <[email protected]>
    Tested-by: Marek Marczykowski-Górecki <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Stable-dep-of: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory")
    Signed-off-by: Sasha Levin <[email protected]>

xen: move checks for e820 conflicts further up [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Tue Aug 6 09:56:48 2024 +0200

    xen: move checks for e820 conflicts further up
    
    commit c4498ae316da5b5786ccd448fc555f3339b8e4ca upstream.
    
    Move the checks for e820 memory map conflicts using the
    xen_chk_is_e820_usable() helper further up in order to prepare
    resolving some of the possible conflicts by doing some e820 map
    modifications, which must happen before evaluating the RAM layout.
    
    Signed-off-by: Juergen Gross <[email protected]>
    Tested-by: Marek Marczykowski-Górecki <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

xen: move max_pfn in xen_memory_setup() out of function scope [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Tue Aug 6 10:24:41 2024 +0200

    xen: move max_pfn in xen_memory_setup() out of function scope
    
    [ Upstream commit 43dc2a0f479b9cd30f6674986d7a40517e999d31 ]
    
    Instead of having max_pfn as a local variable of xen_memory_setup(),
    make it a static variable in setup.c instead. This avoids having to
    pass it to subfunctions, which will be needed in more cases in future.
    
    Rename it to ini_nr_pages, as the value denotes the currently usable
    number of memory pages as passed from the hypervisor at boot time.
    
    Signed-off-by: Juergen Gross <[email protected]>
    Tested-by: Marek Marczykowski-Górecki <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Stable-dep-of: be35d91c8880 ("xen: tolerate ACPI NVS memory overlapping with Xen allocated memory")
    Signed-off-by: Sasha Levin <[email protected]>

xen: tolerate ACPI NVS memory overlapping with Xen allocated memory [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Fri Aug 2 20:14:22 2024 +0200

    xen: tolerate ACPI NVS memory overlapping with Xen allocated memory
    
    [ Upstream commit be35d91c8880650404f3bf813573222dfb106935 ]
    
    In order to minimize required special handling for running as Xen PV
    dom0, the memory layout is modified to match that of the host. This
    requires to have only RAM at the locations where Xen allocated memory
    is living. Unfortunately there seem to be some machines, where ACPI
    NVS is located at 64 MB, resulting in a conflict with the loaded
    kernel or the initial page tables built by Xen.
    
    Avoid this conflict by swapping the ACPI NVS area in the memory map
    with unused RAM. This is possible via modification of the dom0 P2M map.
    Accesses to the ACPI NVS area are done either for saving and restoring
    it across suspend operations (this will work the same way as before),
    or by ACPI code when NVS memory is referenced from other ACPI tables.
    The latter case is handled by a Xen specific indirection of
    acpi_os_ioremap().
    
    While the E820 map can (and should) be modified right away, the P2M
    map can be updated only after memory allocation is working, as the P2M
    map might need to be extended.
    
    Fixes: 808fdb71936c ("xen: check for kernel memory conflicting with memory layout")
    Signed-off-by: Juergen Gross <[email protected]>
    Tested-by: Marek Marczykowski-Górecki <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

xen: use correct end address of kernel for conflict checking [+ + +]
Author: Juergen Gross <[email protected]>
Date:   Sat Aug 3 08:01:22 2024 +0200

    xen: use correct end address of kernel for conflict checking
    
    [ Upstream commit fac1bceeeb04886fc2ee952672e6e6c85ce41dca ]
    
    When running as a Xen PV dom0 the kernel is loaded by the hypervisor
    using a different memory map than that of the host. In order to
    minimize the required changes in the kernel, the kernel adapts its
    memory map to that of the host. In order to do that it is checking
    for conflicts of its load address with the host memory map.
    
    Unfortunately the tested memory range does not include the .brk
    area, which might result in crashes or memory corruption when this
    area does conflict with the memory map of the host.
    
    Fix the test by using the _end label instead of __bss_stop.
    
    Fixes: 808fdb71936c ("xen: check for kernel memory conflicting with memory layout")
    
    Signed-off-by: Juergen Gross <[email protected]>
    Tested-by: Marek Marczykowski-Górecki <[email protected]>
    Reviewed-by: Jan Beulich <[email protected]>
    Signed-off-by: Juergen Gross <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xhci: Add a quirk for writing ERST in high-low order [+ + +]
Author: Daehwan Jung <[email protected]>
Date:   Mon Jun 10 20:39:12 2024 +0900

    xhci: Add a quirk for writing ERST in high-low order
    
    [ Upstream commit bc162403e33e1d57e40994977acaf19f1434e460 ]
    
    This quirk is for the controller that has a limitation in supporting
    separate ERSTBA_HI and ERSTBA_LO programming. It's supported when
    the ERSTBA is programmed ERSTBA_HI before ERSTBA_LO. That's because
    the internal initialization of event ring fetches the
    "Event Ring Segment Table Entry" based on the indication of ERSTBA_LO
    written.
    
    Signed-off-by: Daehwan Jung <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: e5fa8db0be3e ("usb: xhci: fix loss of data on Cadence xHC")
    Signed-off-by: Sasha Levin <[email protected]>

xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them. [+ + +]
Author: Mathias Nyman <[email protected]>
Date:   Thu Sep 5 17:32:59 2024 +0300

    xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.
    
    commit f81dfa3b57c624c56f2bff171c431bc7f5b558f2 upstream.
    
    PCI xHC host should be stopped and xhci driver memory freed before putting
    host to PCI D3 state during PCI remove callback.
    
    Hosts with XHCI_SPURIOUS_WAKEUP quirk did this the wrong way around
    and set the host to D3 before calling usb_hcd_pci_remove(dev), which will
    access the host to stop it, and then free xhci.
    
    Fixes: f1f6d9a8b540 ("xhci: don't dereference a xhci member after removing xhci")
    Cc: [email protected]
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xz: cleanup CRC32 edits from 2018 [+ + +]
Author: Lasse Collin <[email protected]>
Date:   Sun Jul 21 16:36:24 2024 +0300

    xz: cleanup CRC32 edits from 2018
    
    [ Upstream commit 2ee96abef214550d9e92f5143ee3ac1fd1323e67 ]
    
    In 2018, a dependency on <linux/crc32poly.h> was added to avoid
    duplicating the same constant in multiple files.  Two months later it was
    found to be a bad idea and the definition of CRC32_POLY_LE macro was moved
    into xz_private.h to avoid including <linux/crc32poly.h>.
    
    xz_private.h is a wrong place for it too.  Revert back to the upstream
    version which has the poly in xz_crc32_init() in xz_crc32.c.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
    Fixes: 242cdad873a7 ("lib/xz: Put CRC32_POLY_LE in xz_private.h")
    Signed-off-by: Lasse Collin <[email protected]>
    Reviewed-by: Sam James <[email protected]>
    Tested-by: Michael Ellerman <[email protected]> (powerpc)
    Cc: Krzysztof Kozlowski <[email protected]>
    Cc: Herbert Xu <[email protected]>
    Cc: Joel Stanley <[email protected]>
    Cc: Albert Ou <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Emil Renner Berthing <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Jonathan Corbet <[email protected]>
    Cc: Jubin Zhong <[email protected]>
    Cc: Jules Maselbas <[email protected]>
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Paul Walmsley <[email protected]>
    Cc: Randy Dunlap <[email protected]>
    Cc: Rui Li <[email protected]>
    Cc: Simon Glass <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Will Deacon <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>