--- /dev/null
+From 043faef334a1f3d96ae88e1b7618bfa2b4946388 Mon Sep 17 00:00:00 2001
+From: Thorsten Blum <thorsten.blum@linux.dev>
+Date: Thu, 3 Jul 2025 22:06:13 +0200
+Subject: ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()
+
+From: Thorsten Blum <thorsten.blum@linux.dev>
+
+commit 043faef334a1f3d96ae88e1b7618bfa2b4946388 upstream.
+
+Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a
+potential NULL pointer dereference.
+
+Cc: stable@vger.kernel.org
+Fixes: 20869176d7a7 ("ALSA: ad1816a: Use standard print API")
+Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
+Link: https://patch.msgid.link/20250703200616.304309-2-thorsten.blum@linux.dev
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/isa/ad1816a/ad1816a.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/isa/ad1816a/ad1816a.c
++++ b/sound/isa/ad1816a/ad1816a.c
+@@ -98,7 +98,7 @@ static int snd_card_ad1816a_pnp(int dev,
+ pdev = pnp_request_card_device(card, id->devs[1].id, NULL);
+ if (pdev == NULL) {
+ mpu_port[dev] = -1;
+- dev_warn(&pdev->dev, "MPU401 device busy, skipping.\n");
++ pr_warn("MPU401 device busy, skipping.\n");
+ return 0;
+ }
+
--- /dev/null
+From ce174b48aebb3fa18fe48c59a3d10a89c414fdf2 Mon Sep 17 00:00:00 2001
+From: Edip Hazuri <edip@medip.dev>
+Date: Fri, 27 Jun 2025 23:34:16 +0300
+Subject: ALSA: hda/realtek - Add mute LED support for HP Victus 15-fb2xxx
+
+From: Edip Hazuri <edip@medip.dev>
+
+commit ce174b48aebb3fa18fe48c59a3d10a89c414fdf2 upstream.
+
+The mute led on this laptop is using ALC245 but requires a quirk to work
+This patch enables the existing quirk for the device.
+
+Tested on my friend's Victus 15-fb2xxx Laptop. The LED behaviour works
+as intended.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Edip Hazuri <edip@medip.dev>
+Link: https://patch.msgid.link/20250627203415.56785-2-edip@medip.dev
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -10855,6 +10855,7 @@ static const struct hda_quirk alc269_fix
+ SND_PCI_QUIRK(0x103c, 0x8ce0, "HP SnowWhite", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8cf5, "HP ZBook Studio 16", ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8d01, "HP ZBook Power 14 G12", ALC285_FIXUP_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x8d07, "HP Victus 15-fb2xxx (MB 8D07)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT),
+ SND_PCI_QUIRK(0x103c, 0x8d18, "HP EliteStudio 8 AIO", ALC274_FIXUP_HP_AIO_BIND_DACS),
+ SND_PCI_QUIRK(0x103c, 0x8d84, "HP EliteBook X G1i", ALC285_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8d85, "HP EliteBook 14 G12", ALC285_FIXUP_HP_GPIO_LED),
--- /dev/null
+From a75ad2fc76a2ab70817c7eed3163b66ea84ca6ac Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Fri, 20 Jun 2025 12:28:48 +0100
+Subject: arm64: Filter out SME hwcaps when FEAT_SME isn't implemented
+
+From: Mark Brown <broonie@kernel.org>
+
+commit a75ad2fc76a2ab70817c7eed3163b66ea84ca6ac upstream.
+
+We have a number of hwcaps for various SME subfeatures enumerated via
+ID_AA64SMFR0_EL1. Currently we advertise these without cross checking
+against the main SME feature, advertised in ID_AA64PFR1_EL1.SME which
+means that if the two are out of sync userspace can see a confusing
+situation where SME subfeatures are advertised without the base SME
+hwcap. This can be readily triggered by using the arm64.nosme override
+which only masks out ID_AA64PFR1_EL1.SME, and there have also been
+reports of VMMs which do the same thing.
+
+Fix this as we did previously for SVE in 064737920bdb ("arm64: Filter
+out SVE hwcaps when FEAT_SVE isn't implemented") by filtering out the
+SME subfeature hwcaps when FEAT_SME is not present.
+
+Fixes: 5e64b862c482 ("arm64/sme: Basic enumeration support")
+Reported-by: Yury Khrustalev <yury.khrustalev@arm.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20250620-arm64-sme-filter-hwcaps-v1-1-02b9d3c2d8ef@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/cpufeature.c | 57 +++++++++++++++++++++++------------------
+ 1 file changed, 32 insertions(+), 25 deletions(-)
+
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -3122,6 +3122,13 @@ static bool has_sve_feature(const struct
+ }
+ #endif
+
++#ifdef CONFIG_ARM64_SME
++static bool has_sme_feature(const struct arm64_cpu_capabilities *cap, int scope)
++{
++ return system_supports_sme() && has_user_cpuid_feature(cap, scope);
++}
++#endif
++
+ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
+ HWCAP_CAP(ID_AA64ISAR0_EL1, AES, PMULL, CAP_HWCAP, KERNEL_HWCAP_PMULL),
+ HWCAP_CAP(ID_AA64ISAR0_EL1, AES, AES, CAP_HWCAP, KERNEL_HWCAP_AES),
+@@ -3210,31 +3217,31 @@ static const struct arm64_cpu_capabiliti
+ HWCAP_CAP(ID_AA64ISAR2_EL1, BC, IMP, CAP_HWCAP, KERNEL_HWCAP_HBC),
+ #ifdef CONFIG_ARM64_SME
+ HWCAP_CAP(ID_AA64PFR1_EL1, SME, IMP, CAP_HWCAP, KERNEL_HWCAP_SME),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2p2, CAP_HWCAP, KERNEL_HWCAP_SME2P2),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, I16I64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I64),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F64F64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F64F64),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, I16I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16B16),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F16F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F16),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F8F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F16),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F8F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, B16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16F32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, BI32I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_BI32I32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, F32F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F32F32),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8FMA),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP4),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SF8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP2),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SBitPerm, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SBITPERM),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, AES, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_AES),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SFEXPA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SFEXPA),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, STMOP, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_STMOP),
+- HWCAP_CAP(ID_AA64SMFR0_EL1, SMOP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SMOP4),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, FA64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_FA64),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, LUTv2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_LUTV2),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p2, CAP_HWCAP, KERNEL_HWCAP_SME2P2),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2p1, CAP_HWCAP, KERNEL_HWCAP_SME2P1),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMEver, SME2, CAP_HWCAP, KERNEL_HWCAP_SME2),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I16I64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I64),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F64F64, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F64F64),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I16I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I16I32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, B16B16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16B16),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F16F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F16),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F8F16, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F16),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F8F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F8F32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F16F32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, B16F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_B16F32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, BI32I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_BI32I32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, F32F32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_F32F32),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8FMA),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8DP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP4),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SF8DP2, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SF8DP2),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SBitPerm, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SBITPERM),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, AES, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_AES),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SFEXPA, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SFEXPA),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, STMOP, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_STMOP),
++ HWCAP_CAP_MATCH_ID(has_sme_feature, ID_AA64SMFR0_EL1, SMOP4, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_SMOP4),
+ #endif /* CONFIG_ARM64_SME */
+ HWCAP_CAP(ID_AA64FPFR0_EL1, F8CVT, IMP, CAP_HWCAP, KERNEL_HWCAP_F8CVT),
+ HWCAP_CAP(ID_AA64FPFR0_EL1, F8FMA, IMP, CAP_HWCAP, KERNEL_HWCAP_F8FMA),
--- /dev/null
+From dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 Mon Sep 17 00:00:00 2001
+From: Arun Raghavan <arun@asymptotic.io>
+Date: Thu, 26 Jun 2025 09:08:25 -0400
+Subject: ASoC: fsl_sai: Force a software reset when starting in consumer mode
+
+From: Arun Raghavan <arun@asymptotic.io>
+
+commit dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 upstream.
+
+On an imx8mm platform with an external clock provider, when running the
+receiver (arecord) and triggering an xrun with xrun_injection, we see a
+channel swap/offset. This happens sometimes when running only the
+receiver, but occurs reliably if a transmitter (aplay) is also
+concurrently running.
+
+It seems that the SAI loses track of frame sync during the trigger stop
+-> trigger start cycle that occurs during an xrun. Doing just a FIFO
+reset in this case does not suffice, and only a software reset seems to
+get it back on track.
+
+This looks like the same h/w bug that is already handled for the
+producer case, so we now do the reset unconditionally on config disable.
+
+Signed-off-by: Arun Raghavan <arun@asymptotic.io>
+Reported-by: Pieterjan Camerlynck <p.camerlynck@televic.com>
+Fixes: 3e3f8bd56955 ("ASoC: fsl_sai: fix no frame clk in master mode")
+Cc: stable@vger.kernel.org
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/fsl/fsl_sai.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/sound/soc/fsl/fsl_sai.c
++++ b/sound/soc/fsl/fsl_sai.c
+@@ -771,13 +771,15 @@ static void fsl_sai_config_disable(struc
+ * anymore. Add software reset to fix this issue.
+ * This is a hardware bug, and will be fix in the
+ * next sai version.
++ *
++ * In consumer mode, this can happen even after a
++ * single open/close, especially if both tx and rx
++ * are running concurrently.
+ */
+- if (!sai->is_consumer_mode[tx]) {
+- /* Software Reset */
+- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
+- /* Clear SR bit to finish the reset */
+- regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
+- }
++ /* Software Reset */
++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), FSL_SAI_CSR_SR);
++ /* Clear SR bit to finish the reset */
++ regmap_write(sai->regmap, FSL_SAI_xCSR(tx, ofs), 0);
+ }
+
+ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
--- /dev/null
+From e54c5de901ea56fc68f8d56b3cce9940169346f4 Mon Sep 17 00:00:00 2001
+From: Kent Russell <kent.russell@amd.com>
+Date: Tue, 24 Jun 2025 11:42:06 -0400
+Subject: drm/amdgpu: Include sdma_4_4_4.bin
+
+From: Kent Russell <kent.russell@amd.com>
+
+commit e54c5de901ea56fc68f8d56b3cce9940169346f4 upstream.
+
+This got missed during SDMA 4.4.4 support.
+
+Fixes: 968e3811c3e8 ("drm/amdgpu: add initial support for sdma444")
+Signed-off-by: Kent Russell <kent.russell@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 51526efe02714339ed6139f7bc348377d363200a)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c
+index cef68df4c663..bb82c652e4c0 100644
+--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c
++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c
+@@ -45,6 +45,7 @@
+ #include "amdgpu_ras.h"
+
+ MODULE_FIRMWARE("amdgpu/sdma_4_4_2.bin");
++MODULE_FIRMWARE("amdgpu/sdma_4_4_4.bin");
+ MODULE_FIRMWARE("amdgpu/sdma_4_4_5.bin");
+
+ static const struct amdgpu_hwip_reg_entry sdma_reg_list_4_4_2[] = {
+--
+2.50.1
+
--- /dev/null
+From 34659c1a1f4fd4c148ab13e13b11fd64df01ffcd Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 25 Jun 2025 18:15:37 -0400
+Subject: drm/amdkfd: add hqd_sdma_get_doorbell callbacks for gfx7/8
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 34659c1a1f4fd4c148ab13e13b11fd64df01ffcd upstream.
+
+These were missed when support was added for other generations.
+The callbacks are called unconditionally so we need to make
+sure all generations have them.
+
+Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4304
+Link: https://github.com/ROCm/ROCm/issues/4965
+Fixes: bac38ca8c475 ("drm/amdkfd: implement per queue sdma reset for gfx 9.4+")
+Cc: Jonathan Kim <jonathan.kim@amd.com>
+Reported-by: Johl Brown <johlbrown@gmail.com>
+Reviewed-by: Jonathan Kim <jonathan.kim@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit 1e9d17a5dcf1242e9518e461d8e63ad35240e49e)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 8 ++++++++
+ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 8 ++++++++
+ 2 files changed, 16 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
+@@ -561,6 +561,13 @@ static uint32_t read_vmid_from_vmfault_r
+ return REG_GET_FIELD(status, VM_CONTEXT1_PROTECTION_FAULT_STATUS, VMID);
+ }
+
++static uint32_t kgd_hqd_sdma_get_doorbell(struct amdgpu_device *adev,
++ int engine, int queue)
++
++{
++ return 0;
++}
++
+ const struct kfd2kgd_calls gfx_v7_kfd2kgd = {
+ .program_sh_mem_settings = kgd_program_sh_mem_settings,
+ .set_pasid_vmid_mapping = kgd_set_pasid_vmid_mapping,
+@@ -578,4 +585,5 @@ const struct kfd2kgd_calls gfx_v7_kfd2kg
+ .set_scratch_backing_va = set_scratch_backing_va,
+ .set_vm_context_page_table_base = set_vm_context_page_table_base,
+ .read_vmid_from_vmfault_reg = read_vmid_from_vmfault_reg,
++ .hqd_sdma_get_doorbell = kgd_hqd_sdma_get_doorbell,
+ };
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
+@@ -582,6 +582,13 @@ static void set_vm_context_page_table_ba
+ lower_32_bits(page_table_base));
+ }
+
++static uint32_t kgd_hqd_sdma_get_doorbell(struct amdgpu_device *adev,
++ int engine, int queue)
++
++{
++ return 0;
++}
++
+ const struct kfd2kgd_calls gfx_v8_kfd2kgd = {
+ .program_sh_mem_settings = kgd_program_sh_mem_settings,
+ .set_pasid_vmid_mapping = kgd_set_pasid_vmid_mapping,
+@@ -599,4 +606,5 @@ const struct kfd2kgd_calls gfx_v8_kfd2kg
+ get_atc_vmid_pasid_mapping_info,
+ .set_scratch_backing_va = set_scratch_backing_va,
+ .set_vm_context_page_table_base = set_vm_context_page_table_base,
++ .hqd_sdma_get_doorbell = kgd_hqd_sdma_get_doorbell,
+ };
--- /dev/null
+From cf234231fcbc7d391e2135b9518613218cc5347f Mon Sep 17 00:00:00 2001
+From: Philip Yang <Philip.Yang@amd.com>
+Date: Fri, 20 Jun 2025 18:32:32 -0400
+Subject: drm/amdkfd: Don't call mmput from MMU notifier callback
+
+From: Philip Yang <Philip.Yang@amd.com>
+
+commit cf234231fcbc7d391e2135b9518613218cc5347f upstream.
+
+If the process is exiting, the mmput inside mmu notifier callback from
+compactd or fork or numa balancing could release the last reference
+of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
+with below backtrace.
+
+The deadlock will leak kfd process as mmu notifier release is not called
+and cause VRAM leaking.
+
+The fix is to take mm reference mmget_non_zero when adding prange to the
+deferred list to pair with mmput in deferred list work.
+
+If prange split and add into pchild list, the pchild work_item.mm is not
+used, so remove the mm parameter from svm_range_unmap_split and
+svm_range_add_child.
+
+The backtrace of hung task:
+
+ INFO: task python:348105 blocked for more than 64512 seconds.
+ Call Trace:
+ __schedule+0x1c3/0x550
+ schedule+0x46/0xb0
+ rwsem_down_write_slowpath+0x24b/0x4c0
+ unlink_anon_vmas+0xb1/0x1c0
+ free_pgtables+0xa9/0x130
+ exit_mmap+0xbc/0x1a0
+ mmput+0x5a/0x140
+ svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
+ mn_itree_invalidate+0x72/0xc0
+ __mmu_notifier_invalidate_range_start+0x48/0x60
+ try_to_unmap_one+0x10fa/0x1400
+ rmap_walk_anon+0x196/0x460
+ try_to_unmap+0xbb/0x210
+ migrate_page_unmap+0x54d/0x7e0
+ migrate_pages_batch+0x1c3/0xae0
+ migrate_pages_sync+0x98/0x240
+ migrate_pages+0x25c/0x520
+ compact_zone+0x29d/0x590
+ compact_zone_order+0xb6/0xf0
+ try_to_compact_pages+0xbe/0x220
+ __alloc_pages_direct_compact+0x96/0x1a0
+ __alloc_pages_slowpath+0x410/0x930
+ __alloc_pages_nodemask+0x3a9/0x3e0
+ do_huge_pmd_anonymous_page+0xd7/0x3e0
+ __handle_mm_fault+0x5e3/0x5f0
+ handle_mm_fault+0xf7/0x2e0
+ hmm_vma_fault.isra.0+0x4d/0xa0
+ walk_pmd_range.isra.0+0xa8/0x310
+ walk_pud_range+0x167/0x240
+ walk_pgd_range+0x55/0x100
+ __walk_page_range+0x87/0x90
+ walk_page_range+0xf6/0x160
+ hmm_range_fault+0x4f/0x90
+ amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
+ amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
+ init_user_pages+0xb1/0x2a0 [amdgpu]
+ amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
+ kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
+ kfd_ioctl+0x29d/0x500 [amdgpu]
+
+Fixes: fa582c6f3684 ("drm/amdkfd: Use mmget_not_zero in MMU notifier")
+Signed-off-by: Philip Yang <Philip.Yang@amd.com>
+Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 43 ++++++++++++++++-------------------
+ 1 file changed, 20 insertions(+), 23 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
++++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+@@ -1171,13 +1171,12 @@ svm_range_split_head(struct svm_range *p
+ }
+
+ static void
+-svm_range_add_child(struct svm_range *prange, struct mm_struct *mm,
+- struct svm_range *pchild, enum svm_work_list_ops op)
++svm_range_add_child(struct svm_range *prange, struct svm_range *pchild, enum svm_work_list_ops op)
+ {
+ pr_debug("add child 0x%p [0x%lx 0x%lx] to prange 0x%p child list %d\n",
+ pchild, pchild->start, pchild->last, prange, op);
+
+- pchild->work_item.mm = mm;
++ pchild->work_item.mm = NULL;
+ pchild->work_item.op = op;
+ list_add_tail(&pchild->child_list, &prange->child_list);
+ }
+@@ -2394,15 +2393,17 @@ svm_range_add_list_work(struct svm_range
+ prange->work_item.op != SVM_OP_UNMAP_RANGE)
+ prange->work_item.op = op;
+ } else {
+- prange->work_item.op = op;
+-
+- /* Pairs with mmput in deferred_list_work */
+- mmget(mm);
+- prange->work_item.mm = mm;
+- list_add_tail(&prange->deferred_list,
+- &prange->svms->deferred_range_list);
+- pr_debug("add prange 0x%p [0x%lx 0x%lx] to work list op %d\n",
+- prange, prange->start, prange->last, op);
++ /* Pairs with mmput in deferred_list_work.
++ * If process is exiting and mm is gone, don't update mmu notifier.
++ */
++ if (mmget_not_zero(mm)) {
++ prange->work_item.mm = mm;
++ prange->work_item.op = op;
++ list_add_tail(&prange->deferred_list,
++ &prange->svms->deferred_range_list);
++ pr_debug("add prange 0x%p [0x%lx 0x%lx] to work list op %d\n",
++ prange, prange->start, prange->last, op);
++ }
+ }
+ spin_unlock(&svms->deferred_list_lock);
+ }
+@@ -2416,8 +2417,7 @@ void schedule_deferred_list_work(struct
+ }
+
+ static void
+-svm_range_unmap_split(struct mm_struct *mm, struct svm_range *parent,
+- struct svm_range *prange, unsigned long start,
++svm_range_unmap_split(struct svm_range *parent, struct svm_range *prange, unsigned long start,
+ unsigned long last)
+ {
+ struct svm_range *head;
+@@ -2438,12 +2438,12 @@ svm_range_unmap_split(struct mm_struct *
+ svm_range_split(tail, last + 1, tail->last, &head);
+
+ if (head != prange && tail != prange) {
+- svm_range_add_child(parent, mm, head, SVM_OP_UNMAP_RANGE);
+- svm_range_add_child(parent, mm, tail, SVM_OP_ADD_RANGE);
++ svm_range_add_child(parent, head, SVM_OP_UNMAP_RANGE);
++ svm_range_add_child(parent, tail, SVM_OP_ADD_RANGE);
+ } else if (tail != prange) {
+- svm_range_add_child(parent, mm, tail, SVM_OP_UNMAP_RANGE);
++ svm_range_add_child(parent, tail, SVM_OP_UNMAP_RANGE);
+ } else if (head != prange) {
+- svm_range_add_child(parent, mm, head, SVM_OP_UNMAP_RANGE);
++ svm_range_add_child(parent, head, SVM_OP_UNMAP_RANGE);
+ } else if (parent != prange) {
+ prange->work_item.op = SVM_OP_UNMAP_RANGE;
+ }
+@@ -2520,14 +2520,14 @@ svm_range_unmap_from_cpu(struct mm_struc
+ l = min(last, pchild->last);
+ if (l >= s)
+ svm_range_unmap_from_gpus(pchild, s, l, trigger);
+- svm_range_unmap_split(mm, prange, pchild, start, last);
++ svm_range_unmap_split(prange, pchild, start, last);
+ mutex_unlock(&pchild->lock);
+ }
+ s = max(start, prange->start);
+ l = min(last, prange->last);
+ if (l >= s)
+ svm_range_unmap_from_gpus(prange, s, l, trigger);
+- svm_range_unmap_split(mm, prange, prange, start, last);
++ svm_range_unmap_split(prange, prange, start, last);
+
+ if (unmap_parent)
+ svm_range_add_list_work(svms, prange, mm, SVM_OP_UNMAP_RANGE);
+@@ -2570,8 +2570,6 @@ svm_range_cpu_invalidate_pagetables(stru
+
+ if (range->event == MMU_NOTIFY_RELEASE)
+ return true;
+- if (!mmget_not_zero(mni->mm))
+- return true;
+
+ start = mni->interval_tree.start;
+ last = mni->interval_tree.last;
+@@ -2598,7 +2596,6 @@ svm_range_cpu_invalidate_pagetables(stru
+ }
+
+ svm_range_unlock(prange);
+- mmput(mni->mm);
+
+ return true;
+ }
--- /dev/null
+From d38376b3ee48d073c64e75e150510d7e6b4b04f7 Mon Sep 17 00:00:00 2001
+From: Alessio Belle <alessio.belle@imgtec.com>
+Date: Tue, 24 Jun 2025 15:22:08 +0100
+Subject: drm/imagination: Fix kernel crash when hard resetting the GPU
+
+From: Alessio Belle <alessio.belle@imgtec.com>
+
+commit d38376b3ee48d073c64e75e150510d7e6b4b04f7 upstream.
+
+The GPU hard reset sequence calls pm_runtime_force_suspend() and
+pm_runtime_force_resume(), which according to their documentation should
+only be used during system-wide PM transitions to sleep states.
+
+The main issue though is that depending on some internal runtime PM
+state as seen by pm_runtime_force_suspend() (whether the usage count is
+<= 1), pm_runtime_force_resume() might not resume the device unless
+needed. If that happens, the runtime PM resume callback
+pvr_power_device_resume() is not called, the GPU clocks are not
+re-enabled, and the kernel crashes on the next attempt to access GPU
+registers as part of the power-on sequence.
+
+Replace calls to pm_runtime_force_suspend() and
+pm_runtime_force_resume() with direct calls to the driver's runtime PM
+callbacks, pvr_power_device_suspend() and pvr_power_device_resume(),
+to ensure clocks are re-enabled and avoid the kernel crash.
+
+Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support")
+Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
+Reviewed-by: Matt Coster <matt.coster@imgtec.com>
+Link: https://lore.kernel.org/r/20250624-fix-kernel-crash-gpu-hard-reset-v1-1-6d24810d72a6@imgtec.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Matt Coster <matt.coster@imgtec.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/imagination/pvr_power.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/imagination/pvr_power.c
++++ b/drivers/gpu/drm/imagination/pvr_power.c
+@@ -363,13 +363,13 @@ pvr_power_reset(struct pvr_device *pvr_d
+ if (!err) {
+ if (hard_reset) {
+ pvr_dev->fw_dev.booted = false;
+- WARN_ON(pm_runtime_force_suspend(from_pvr_device(pvr_dev)->dev));
++ WARN_ON(pvr_power_device_suspend(from_pvr_device(pvr_dev)->dev));
+
+ err = pvr_fw_hard_reset(pvr_dev);
+ if (err)
+ goto err_device_lost;
+
+- err = pm_runtime_force_resume(from_pvr_device(pvr_dev)->dev);
++ err = pvr_power_device_resume(from_pvr_device(pvr_dev)->dev);
+ pvr_dev->fw_dev.booted = true;
+ if (err)
+ goto err_device_lost;
--- /dev/null
+From 30e0fd3c0273dc106320081793793a424f1f1950 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Thu, 3 Jul 2025 15:18:29 -0400
+Subject: gpiolib: fix performance regression when using gpio_chip_get_multiple()
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit 30e0fd3c0273dc106320081793793a424f1f1950 upstream.
+
+commit 74abd086d2ee ("gpiolib: sanitize the return value of
+gpio_chip::get_multiple()") altered the value returned by
+gc->get_multiple() in case it is positive (> 0), but failed to return
+for other cases (<= 0).
+
+This may result in the "if (gc->get)" block being executed and thus
+negates the performance gain that is normally obtained by using
+gc->get_multiple().
+
+Fix by returning the result of gc->get_multiple() if it is <= 0.
+
+Also move the "ret" variable to the scope where it is used, which as an
+added bonus fixes an indentation error introduced by the aforementioned
+commit.
+
+Fixes: 74abd086d2ee ("gpiolib: sanitize the return value of gpio_chip::get_multiple()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://lore.kernel.org/r/20250703191829.2952986-1-hugo@hugovil.com
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpiolib.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -3277,14 +3277,15 @@ static int gpiod_get_raw_value_commit(co
+ static int gpio_chip_get_multiple(struct gpio_chip *gc,
+ unsigned long *mask, unsigned long *bits)
+ {
+- int ret;
+-
+ lockdep_assert_held(&gc->gpiodev->srcu);
+
+ if (gc->get_multiple) {
++ int ret;
++
+ ret = gc->get_multiple(gc, mask, bits);
+ if (ret > 0)
+ return -EBADE;
++ return ret;
+ }
+
+ if (gc->get) {
--- /dev/null
+From 4e914ef063de40397e25a025c70d9737a9e45a8c Mon Sep 17 00:00:00 2001
+From: Guillaume Nault <gnault@redhat.com>
+Date: Wed, 9 Jul 2025 16:30:10 +0200
+Subject: gre: Fix IPv6 multicast route creation.
+
+From: Guillaume Nault <gnault@redhat.com>
+
+commit 4e914ef063de40397e25a025c70d9737a9e45a8c upstream.
+
+Use addrconf_add_dev() instead of ipv6_find_idev() in
+addrconf_gre_config() so that we don't just get the inet6_dev, but also
+install the default ff00::/8 multicast route.
+
+Before commit 3e6a0243ff00 ("gre: Fix again IPv6 link-local address
+generation."), the multicast route was created at the end of the
+function by addrconf_add_mroute(). But this code path is now only taken
+in one particular case (gre devices not bound to a local IP address and
+in EUI64 mode). For all other cases, the function exits early and
+addrconf_add_mroute() is not called anymore.
+
+Using addrconf_add_dev() instead of ipv6_find_idev() in
+addrconf_gre_config(), fixes the problem as it will create the default
+multicast route for all gre devices. This also brings
+addrconf_gre_config() a bit closer to the normal netdevice IPv6
+configuration code (addrconf_dev_config()).
+
+Cc: stable@vger.kernel.org
+Fixes: 3e6a0243ff00 ("gre: Fix again IPv6 link-local address generation.")
+Reported-by: Aiden Yang <ling@moedove.com>
+Closes: https://lore.kernel.org/netdev/CANR=AhRM7YHHXVxJ4DmrTNMeuEOY87K2mLmo9KMed1JMr20p6g@mail.gmail.com/
+Reviewed-by: Gary Guo <gary@garyguo.net>
+Tested-by: Gary Guo <gary@garyguo.net>
+Signed-off-by: Guillaume Nault <gnault@redhat.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Link: https://patch.msgid.link/027a923dcb550ad115e6d93ee8bb7d310378bd01.1752070620.git.gnault@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/addrconf.c | 9 ++-------
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+--- a/net/ipv6/addrconf.c
++++ b/net/ipv6/addrconf.c
+@@ -3525,11 +3525,9 @@ static void addrconf_gre_config(struct n
+
+ ASSERT_RTNL();
+
+- idev = ipv6_find_idev(dev);
+- if (IS_ERR(idev)) {
+- pr_debug("%s: add_dev failed\n", __func__);
++ idev = addrconf_add_dev(dev);
++ if (IS_ERR(idev))
+ return;
+- }
+
+ /* Generate the IPv6 link-local address using addrconf_addr_gen(),
+ * unless we have an IPv4 GRE device not bound to an IP address and
+@@ -3543,9 +3541,6 @@ static void addrconf_gre_config(struct n
+ }
+
+ add_v4_addrs(idev);
+-
+- if (dev->flags & IFF_POINTOPOINT)
+- addrconf_add_mroute(dev);
+ }
+ #endif
+
--- /dev/null
+From fc582cd26e888b0652bc1494f252329453fd3b23 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 8 Jul 2025 11:00:32 -0600
+Subject: io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit fc582cd26e888b0652bc1494f252329453fd3b23 upstream.
+
+syzbot reports that defer/local task_work adding via msg_ring can hit
+a request that has been freed:
+
+CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
+ print_address_description mm/kasan/report.c:408 [inline]
+ print_report+0xd2/0x2b0 mm/kasan/report.c:521
+ kasan_report+0x118/0x150 mm/kasan/report.c:634
+ io_req_local_work_add io_uring/io_uring.c:1184 [inline]
+ __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252
+ io_msg_remote_post io_uring/msg_ring.c:103 [inline]
+ io_msg_data_remote io_uring/msg_ring.c:133 [inline]
+ __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151
+ io_msg_ring_data io_uring/msg_ring.c:173 [inline]
+ io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314
+ __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739
+ io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762
+ io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874
+ io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642
+ io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696
+ ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
+ ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
+ </TASK>
+
+which is supposed to be safe with how requests are allocated. But msg
+ring requests alloc and free on their own, and hence must defer freeing
+to a sane time.
+
+Add an rcu_head and use kfree_rcu() in both spots where requests are
+freed. Only the one in io_msg_tw_complete() is strictly required as it
+has been visible on the other ring, but use it consistently in the other
+spot as well.
+
+This should not cause any other issues outside of KASAN rightfully
+complaining about it.
+
+Link: https://lore.kernel.org/io-uring/686cd2ea.a00a0220.338033.0007.GAE@google.com/
+Reported-by: syzbot+54cbbfb4db9145d26fc2@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Fixes: 0617bb500bfa ("io_uring/msg_ring: improve handling of target CQE posting")
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/io_uring_types.h | 2 ++
+ io_uring/msg_ring.c | 4 ++--
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+--- a/include/linux/io_uring_types.h
++++ b/include/linux/io_uring_types.h
+@@ -701,6 +701,8 @@ struct io_kiocb {
+ struct hlist_node hash_node;
+ /* For IOPOLL setup queues, with hybrid polling */
+ u64 iopoll_start;
++ /* for private io_kiocb freeing */
++ struct rcu_head rcu_head;
+ };
+ /* internal polling, see IORING_FEAT_FAST_POLL */
+ struct async_poll *apoll;
+--- a/io_uring/msg_ring.c
++++ b/io_uring/msg_ring.c
+@@ -82,7 +82,7 @@ static void io_msg_tw_complete(struct io
+ spin_unlock(&ctx->msg_lock);
+ }
+ if (req)
+- kmem_cache_free(req_cachep, req);
++ kfree_rcu(req, rcu_head);
+ percpu_ref_put(&ctx->refs);
+ }
+
+@@ -90,7 +90,7 @@ static int io_msg_remote_post(struct io_
+ int res, u32 cflags, u64 user_data)
+ {
+ if (!READ_ONCE(ctx->submitter_task)) {
+- kmem_cache_free(req_cachep, req);
++ kfree_rcu(req, rcu_head);
+ return -EOWNERDEAD;
+ }
+ req->opcode = IORING_OP_NOP;
--- /dev/null
+From 47bb584237cc285e3a860b70c01f7bda9dcfb05b Mon Sep 17 00:00:00 2001
+From: Liam Merwick <liam.merwick@oracle.com>
+Date: Mon, 9 Jun 2025 09:11:19 +0000
+Subject: KVM: Allow CPU to reschedule while setting per-page memory attributes
+
+From: Liam Merwick <liam.merwick@oracle.com>
+
+commit 47bb584237cc285e3a860b70c01f7bda9dcfb05b upstream.
+
+When running an SEV-SNP guest with a sufficiently large amount of memory (1TB+),
+the host can experience CPU soft lockups when running an operation in
+kvm_vm_set_mem_attributes() to set memory attributes on the whole
+range of guest memory.
+
+watchdog: BUG: soft lockup - CPU#8 stuck for 26s! [qemu-kvm:6372]
+CPU: 8 UID: 0 PID: 6372 Comm: qemu-kvm Kdump: loaded Not tainted 6.15.0-rc7.20250520.el9uek.rc1.x86_64 #1 PREEMPT(voluntary)
+Hardware name: Oracle Corporation ORACLE SERVER E4-2c/Asm,MB Tray,2U,E4-2c, BIOS 78016600 11/13/2024
+RIP: 0010:xas_create+0x78/0x1f0
+Code: 00 00 00 41 80 fc 01 0f 84 82 00 00 00 ba 06 00 00 00 bd 06 00 00 00 49 8b 45 08 4d 8d 65 08 41 39 d6 73 20 83 ed 06 48 85 c0 <74> 67 48 89 c2 83 e2 03 48 83 fa 02 75 0c 48 3d 00 10 00 00 0f 87
+RSP: 0018:ffffad890a34b940 EFLAGS: 00000286
+RAX: ffff96f30b261daa RBX: ffffad890a34b9c8 RCX: 0000000000000000
+RDX: 000000000000001e RSI: 0000000000000000 RDI: 0000000000000000
+RBP: 0000000000000018 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000000 R12: ffffad890a356868
+R13: ffffad890a356860 R14: 0000000000000000 R15: ffffad890a356868
+FS: 00007f5578a2a400(0000) GS:ffff97ed317e1000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f015c70fb18 CR3: 00000001109fd006 CR4: 0000000000f70ef0
+PKRU: 55555554
+Call Trace:
+ <TASK>
+ xas_store+0x58/0x630
+ __xa_store+0xa5/0x130
+ xa_store+0x2c/0x50
+ kvm_vm_set_mem_attributes+0x343/0x710 [kvm]
+ kvm_vm_ioctl+0x796/0xab0 [kvm]
+ __x64_sys_ioctl+0xa3/0xd0
+ do_syscall_64+0x8c/0x7a0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+RIP: 0033:0x7f5578d031bb
+Code: ff ff ff 85 c0 79 9b 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2d 4c 0f 00 f7 d8 64 89 01 48
+RSP: 002b:00007ffe0a742b88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
+RAX: ffffffffffffffda RBX: 000000004020aed2 RCX: 00007f5578d031bb
+RDX: 00007ffe0a742c80 RSI: 000000004020aed2 RDI: 000000000000000b
+RBP: 0000010000000000 R08: 0000010000000000 R09: 0000017680000000
+R10: 0000000000000080 R11: 0000000000000246 R12: 00005575e5f95120
+R13: 00007ffe0a742c80 R14: 0000000000000008 R15: 00005575e5f961e0
+
+While looping through the range of memory setting the attributes,
+call cond_resched() to give the scheduler a chance to run a higher
+priority task on the runqueue if necessary and avoid staying in
+kernel mode long enough to trigger the lockup.
+
+Fixes: 5a475554db1e ("KVM: Introduce per-page memory attributes")
+Cc: stable@vger.kernel.org # 6.12.x
+Suggested-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Liam Merwick <liam.merwick@oracle.com>
+Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com>
+Link: https://lore.kernel.org/r/20250609091121.2497429-2-liam.merwick@oracle.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ virt/kvm/kvm_main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -2515,6 +2515,8 @@ static int kvm_vm_set_mem_attributes(str
+ r = xa_reserve(&kvm->mem_attr_array, i, GFP_KERNEL_ACCOUNT);
+ if (r)
+ goto out_unlock;
++
++ cond_resched();
+ }
+
+ kvm_handle_gfn_range(kvm, &pre_set_range);
+@@ -2523,6 +2525,7 @@ static int kvm_vm_set_mem_attributes(str
+ r = xa_err(xa_store(&kvm->mem_attr_array, i, entry,
+ GFP_KERNEL_ACCOUNT));
+ KVM_BUG_ON(r, kvm);
++ cond_resched();
+ }
+
+ kvm_handle_gfn_range(kvm, &post_set_range);
--- /dev/null
+From 51a4273dcab39dd1e850870945ccec664352d383 Mon Sep 17 00:00:00 2001
+From: Nikunj A Dadhania <nikunj@amd.com>
+Date: Tue, 8 Apr 2025 15:02:11 +0530
+Subject: KVM: SVM: Add missing member in SNP_LAUNCH_START command structure
+
+From: Nikunj A Dadhania <nikunj@amd.com>
+
+commit 51a4273dcab39dd1e850870945ccec664352d383 upstream.
+
+The sev_data_snp_launch_start structure should include a 4-byte
+desired_tsc_khz field before the gosvw field, which was missed in the
+initial implementation. As a result, the structure is 4 bytes shorter than
+expected by the firmware, causing the gosvw field to start 4 bytes early.
+Fix this by adding the missing 4-byte member for the desired TSC frequency.
+
+Fixes: 3a45dc2b419e ("crypto: ccp: Define the SEV-SNP commands")
+Cc: stable@vger.kernel.org
+Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
+Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
+Tested-by: Vaishali Thakkar <vaishali.thakkar@suse.com>
+Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
+Link: https://lore.kernel.org/r/20250408093213.57962-3-nikunj@amd.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/psp-sev.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/include/linux/psp-sev.h
++++ b/include/linux/psp-sev.h
+@@ -594,6 +594,7 @@ struct sev_data_snp_addr {
+ * @imi_en: launch flow is launching an IMI (Incoming Migration Image) for the
+ * purpose of guest-assisted migration.
+ * @rsvd: reserved
++ * @desired_tsc_khz: hypervisor desired mean TSC freq in kHz of the guest
+ * @gosvw: guest OS-visible workarounds, as defined by hypervisor
+ */
+ struct sev_data_snp_launch_start {
+@@ -603,6 +604,7 @@ struct sev_data_snp_launch_start {
+ u32 ma_en:1; /* In */
+ u32 imi_en:1; /* In */
+ u32 rsvd:30;
++ u32 desired_tsc_khz; /* In */
+ u8 gosvw[16]; /* In */
+ } __packed;
+
--- /dev/null
+From ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Mon, 2 Jun 2025 15:44:58 -0700
+Subject: KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit ecf371f8b02d5e31b9aa1da7f159f1b2107bdb01 upstream.
+
+Reject migration of SEV{-ES} state if either the source or destination VM
+is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the
+section between incrementing created_vcpus and online_vcpus. The bulk of
+vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs
+in parallel, and so sev_info.es_active can get toggled from false=>true in
+the destination VM after (or during) svm_vcpu_create(), resulting in an
+SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.
+
+The issue manifests most visibly as a crash when trying to free a vCPU's
+NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.
+
+ BUG: unable to handle page fault for address: ffffebde00000000
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ PGD 0 P4D 0
+ Oops: Oops: 0000 [#1] SMP KASAN NOPTI
+ CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE
+ Tainted: [U]=USER, [O]=OOT_MODULE
+ Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024
+ RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]
+ RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]
+ RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]
+ RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]
+ RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067
+ Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0
+ RSP: 0018:ffff8984551978d0 EFLAGS: 00010246
+ RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98
+ RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000
+ RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000
+ R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000
+ R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000
+ FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0
+ DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+ Call Trace:
+ <TASK>
+ sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169
+ svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515
+ kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396
+ kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]
+ kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490
+ kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895
+ kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310
+ kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369
+ __fput+0x3e4/0x9e0 fs/file_table.c:465
+ task_work_run+0x1a9/0x220 kernel/task_work.c:227
+ exit_task_work include/linux/task_work.h:40 [inline]
+ do_exit+0x7f0/0x25b0 kernel/exit.c:953
+ do_group_exit+0x203/0x2d0 kernel/exit.c:1102
+ get_signal+0x1357/0x1480 kernel/signal.c:3034
+ arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337
+ exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
+ exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
+ __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
+ syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218
+ do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+ RIP: 0033:0x7f87a898e969
+ </TASK>
+ Modules linked in: gq(O)
+ gsmi: Log Shutdown Reason 0x03
+ CR2: ffffebde00000000
+ ---[ end trace 0000000000000000 ]---
+
+Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing
+the host is likely desirable due to the VMSA being consumed by hardware.
+E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a
+bogus VMSA page. Accessing PFN 0 is "fine"-ish now that it's sequestered
+away thanks to L1TF, but panicking in this scenario is preferable to
+potentially running with corrupted state.
+
+Reported-by: Alexander Potapenko <glider@google.com>
+Tested-by: Alexander Potapenko <glider@google.com>
+Fixes: 0b020f5af092 ("KVM: SEV: Add support for SEV-ES intra host migration")
+Fixes: b56639318bb2 ("KVM: SEV: Add support for SEV intra host migration")
+Cc: stable@vger.kernel.org
+Cc: James Houghton <jthoughton@google.com>
+Cc: Peter Gonda <pgonda@google.com>
+Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
+Tested-by: Liam Merwick <liam.merwick@oracle.com>
+Reviewed-by: James Houghton <jthoughton@google.com>
+Link: https://lore.kernel.org/r/20250602224459.41505-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/sev.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/kvm/svm/sev.c
++++ b/arch/x86/kvm/svm/sev.c
+@@ -2032,6 +2032,10 @@ static int sev_check_source_vcpus(struct
+ struct kvm_vcpu *src_vcpu;
+ unsigned long i;
+
++ if (src->created_vcpus != atomic_read(&src->online_vcpus) ||
++ dst->created_vcpus != atomic_read(&dst->online_vcpus))
++ return -EBUSY;
++
+ if (!sev_es_guest(src))
+ return 0;
+
--- /dev/null
+From fa787ac07b3ceb56dd88a62d1866038498e96230 Mon Sep 17 00:00:00 2001
+From: Manuel Andreas <manuel.andreas@tum.de>
+Date: Wed, 25 Jun 2025 15:53:19 +0200
+Subject: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush
+
+From: Manuel Andreas <manuel.andreas@tum.de>
+
+commit fa787ac07b3ceb56dd88a62d1866038498e96230 upstream.
+
+In KVM guests with Hyper-V hypercalls enabled, the hypercalls
+HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
+allow a guest to request invalidation of portions of a virtual TLB.
+For this, the hypercall parameter includes a list of GVAs that are supposed
+to be invalidated.
+
+However, when non-canonical GVAs are passed, there is currently no
+filtering in place and they are eventually passed to checked invocations of
+INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores
+non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly
+signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
+
+ invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000
+ WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482
+ invvpid_error+0x91/0xa0 [kvm_intel]
+ Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse
+ CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)
+ RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
+ Call Trace:
+ vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
+ kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
+ kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
+
+Hyper-V documents that invalid GVAs (those that are beyond a partition's
+GVA space) are to be ignored. While not completely clear whether this
+ruling also applies to non-canonical GVAs, it is likely fine to make that
+assumption, and manual testing on Azure confirms "real" Hyper-V interprets
+the specification in the same way.
+
+Skip non-canonical GVAs when processing the list of address to avoid
+tripping the INVVPID failure. Alternatively, KVM could filter out "bad"
+GVAs before inserting into the FIFO, but practically speaking the only
+downside of pushing validation to the final processing is that doing so
+is suboptimal for the guest, and no well-behaved guest will request TLB
+flushes for non-canonical addresses.
+
+Fixes: 260970862c88 ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently")
+Cc: stable@vger.kernel.org
+Signed-off-by: Manuel Andreas <manuel.andreas@tum.de>
+Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Link: https://lore.kernel.org/r/c090efb3-ef82-499f-a5e0-360fc8420fb7@tum.de
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/hyperv.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/x86/kvm/hyperv.c
++++ b/arch/x86/kvm/hyperv.c
+@@ -1979,6 +1979,9 @@ int kvm_hv_vcpu_flush_tlb(struct kvm_vcp
+ if (entries[i] == KVM_HV_TLB_FLUSHALL_ENTRY)
+ goto out_flush_all;
+
++ if (is_noncanonical_invlpg_address(entries[i], vcpu))
++ continue;
++
+ /*
+ * Lower 12 bits of 'address' encode the number of additional
+ * pages to flush.
--- /dev/null
+From a7f4dff21fd744d08fa956c243d2b1795f23cbf7 Mon Sep 17 00:00:00 2001
+From: David Woodhouse <dwmw@amazon.co.uk>
+Date: Thu, 8 May 2025 13:30:12 -0700
+Subject: KVM: x86/xen: Allow 'out of range' event channel ports in IRQ routing table.
+
+From: David Woodhouse <dwmw@amazon.co.uk>
+
+commit a7f4dff21fd744d08fa956c243d2b1795f23cbf7 upstream.
+
+To avoid imposing an ordering constraint on userspace, allow 'invalid'
+event channel targets to be configured in the IRQ routing table.
+
+This is the same as accepting interrupts targeted at vCPUs which don't
+exist yet, which is already the case for both Xen event channels *and*
+for MSIs (which don't do any filtering of permitted APIC ID targets at
+all).
+
+If userspace actually *triggers* an IRQ with an invalid target, that
+will fail cleanly, as kvm_xen_set_evtchn_fast() also does the same range
+check.
+
+If KVM enforced that the IRQ target must be valid at the time it is
+*configured*, that would force userspace to create all vCPUs and do
+various other parts of setup (in this case, setting the Xen long_mode)
+before restoring the IRQ table.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
+Reviewed-by: Paul Durrant <paul@xen.org>
+Link: https://lore.kernel.org/r/e489252745ac4b53f1f7f50570b03fb416aa2065.camel@infradead.org
+[sean: massage comment]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/xen.c | 15 +++++++++++++--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/xen.c
++++ b/arch/x86/kvm/xen.c
+@@ -1970,8 +1970,19 @@ int kvm_xen_setup_evtchn(struct kvm *kvm
+ {
+ struct kvm_vcpu *vcpu;
+
+- if (ue->u.xen_evtchn.port >= max_evtchn_port(kvm))
+- return -EINVAL;
++ /*
++ * Don't check for the port being within range of max_evtchn_port().
++ * Userspace can configure what ever targets it likes; events just won't
++ * be delivered if/while the target is invalid, just like userspace can
++ * configure MSIs which target non-existent APICs.
++ *
++ * This allow on Live Migration and Live Update, the IRQ routing table
++ * can be restored *independently* of other things like creating vCPUs,
++ * without imposing an ordering dependency on userspace. In this
++ * particular case, the problematic ordering would be with setting the
++ * Xen 'long mode' flag, which changes max_evtchn_port() to allow 4096
++ * instead of 1024 event channels.
++ */
+
+ /* We only support 2 level event channels for now */
+ if (ue->u.xen_evtchn.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL)
--- /dev/null
+From c17fb542dbd1db745c9feac15617056506dd7195 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?H=C3=A5kon=20Bugge?= <haakon.bugge@oracle.com>
+Date: Wed, 2 Jul 2025 11:10:34 +0200
+Subject: md/md-bitmap: fix GPF in bitmap_get_stats()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: HÃ¥kon Bugge <haakon.bugge@oracle.com>
+
+commit c17fb542dbd1db745c9feac15617056506dd7195 upstream.
+
+The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats
+collection for external bitmaps") states:
+
+ Remove the external bitmap check as the statistics should be
+ available regardless of bitmap storage location.
+
+ Return -EINVAL only for invalid bitmap with no storage (neither in
+ superblock nor in external file).
+
+But, the code does not adhere to the above, as it does only check for
+a valid super-block for "internal" bitmaps. Hence, we observe:
+
+Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028
+RIP: 0010:bitmap_get_stats+0x45/0xd0
+Call Trace:
+
+ seq_read_iter+0x2b9/0x46a
+ seq_read+0x12f/0x180
+ proc_reg_read+0x57/0xb0
+ vfs_read+0xf6/0x380
+ ksys_read+0x6d/0xf0
+ do_syscall_64+0x8c/0x1b0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+We fix this by checking the existence of a super-block for both the
+internal and external case.
+
+Fixes: 6ec1f0239485 ("md/md-bitmap: fix stats collection for external bitmaps")
+Cc: stable@vger.kernel.org
+Reported-by: Gerald Gibson <gerald.gibson@oracle.com>
+Signed-off-by: HÃ¥kon Bugge <haakon.bugge@oracle.com>
+Link: https://lore.kernel.org/linux-raid/20250702091035.2061312-1-haakon.bugge@oracle.com
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/md-bitmap.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/md/md-bitmap.c
++++ b/drivers/md/md-bitmap.c
+@@ -2357,8 +2357,7 @@ static int bitmap_get_stats(void *data,
+
+ if (!bitmap)
+ return -ENOENT;
+- if (!bitmap->mddev->bitmap_info.external &&
+- !bitmap->storage.sb_page)
++ if (!bitmap->storage.sb_page)
+ return -EINVAL;
+ sb = kmap_local_page(bitmap->storage.sb_page);
+ stats->sync_size = le64_to_cpu(sb->sync_size);
--- /dev/null
+From 95a234f6affbf51f06338383537ab80d637bb785 Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <haoxiang_li2024@163.com>
+Date: Thu, 3 Jul 2025 18:01:09 +0800
+Subject: net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Haoxiang Li <haoxiang_li2024@163.com>
+
+commit 95a234f6affbf51f06338383537ab80d637bb785 upstream.
+
+Add check for the return value of rcar_gen4_ptp_alloc()
+to prevent potential null pointer dereference.
+
+Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
+Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
+Link: https://patch.msgid.link/20250703100109.2541018-1-haoxiang_li2024@163.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/renesas/rtsn.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/net/ethernet/renesas/rtsn.c
++++ b/drivers/net/ethernet/renesas/rtsn.c
+@@ -1259,7 +1259,12 @@ static int rtsn_probe(struct platform_de
+ priv = netdev_priv(ndev);
+ priv->pdev = pdev;
+ priv->ndev = ndev;
++
+ priv->ptp_priv = rcar_gen4_ptp_alloc(pdev);
++ if (!priv->ptp_priv) {
++ ret = -ENOMEM;
++ goto error_free;
++ }
+
+ spin_lock_init(&priv->lock);
+ platform_set_drvdata(pdev, priv);
--- /dev/null
+From 46147490b4098e200b7d7d3ac4637a3e4f7b806a Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Fri, 13 Jun 2025 20:13:12 +0200
+Subject: pinctrl: nuvoton: Fix boot on ma35dx platforms
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 46147490b4098e200b7d7d3ac4637a3e4f7b806a upstream.
+
+As part of a wider cleanup trying to get rid of OF specific APIs, an
+incorrect (and partially unrelated) cleanup was introduced.
+
+The goal was to replace a device_for_each_chil_node() loop including an
+additional condition inside by a macro doing both the loop and the
+check on a single line.
+
+The snippet:
+
+ device_for_each_child_node(dev, child)
+ if (fwnode_property_present(child, "gpio-controller"))
+ continue;
+
+was replaced by:
+
+ for_each_gpiochip_node(dev, child)
+
+which expands into:
+
+ device_for_each_child_node(dev, child)
+ for_each_if(fwnode_property_present(child, "gpio-controller"))
+
+This change is actually doing the opposite of what was initially
+expected, breaking the probe of this driver, breaking at the same time
+the whole boot of Nuvoton platforms (no more console, the kernel WARN()).
+
+Revert these two changes to roll back to the correct behavior.
+
+Fixes: 693c9ecd8326 ("pinctrl: nuvoton: Reduce use of OF-specific APIs")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/20250613181312.1269794-1-miquel.raynal@bootlin.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/nuvoton/pinctrl-ma35.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/pinctrl/nuvoton/pinctrl-ma35.c b/drivers/pinctrl/nuvoton/pinctrl-ma35.c
+index 06ae1fe8b8c5..b51704bafd81 100644
+--- a/drivers/pinctrl/nuvoton/pinctrl-ma35.c
++++ b/drivers/pinctrl/nuvoton/pinctrl-ma35.c
+@@ -1074,7 +1074,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct
+ u32 idx = 0;
+ int ret;
+
+- for_each_gpiochip_node(dev, child) {
++ device_for_each_child_node(dev, child) {
++ if (fwnode_property_present(child, "gpio-controller"))
++ continue;
++
+ npctl->nfunctions++;
+ npctl->ngroups += of_get_child_count(to_of_node(child));
+ }
+@@ -1092,7 +1095,10 @@ static int ma35_pinctrl_probe_dt(struct platform_device *pdev, struct ma35_pinct
+ if (!npctl->groups)
+ return -ENOMEM;
+
+- for_each_gpiochip_node(dev, child) {
++ device_for_each_child_node(dev, child) {
++ if (fwnode_property_present(child, "gpio-controller"))
++ continue;
++
+ ret = ma35_pinctrl_parse_functions(child, npctl, idx++);
+ if (ret) {
+ fwnode_handle_put(child);
+--
+2.50.1
+
--- /dev/null
+From 93712205ce2f1fb047739494c0399a26ea4f0890 Mon Sep 17 00:00:00 2001
+From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Date: Thu, 12 Jun 2025 11:14:48 +0200
+Subject: pinctrl: qcom: msm: mark certain pins as invalid for interrupts
+
+From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+commit 93712205ce2f1fb047739494c0399a26ea4f0890 upstream.
+
+On some platforms, the UFS-reset pin has no interrupt logic in TLMM but
+is nevertheless registered as a GPIO in the kernel. This enables the
+user-space to trigger a BUG() in the pinctrl-msm driver by running, for
+example: `gpiomon -c 0 113` on RB2.
+
+The exact culprit is requesting pins whose intr_detection_width setting
+is not 1 or 2 for interrupts. This hits a BUG() in
+msm_gpio_irq_set_type(). Potentially crashing the kernel due to an
+invalid request from user-space is not optimal, so let's go through the
+pins and mark those that would fail the check as invalid for the irq chip
+as we should not even register them as available irqs.
+
+This function can be extended if we determine that there are more
+corner-cases like this.
+
+Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
+Cc: stable@vger.kernel.org
+Reviewed-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Link: https://lore.kernel.org/20250612091448.41546-1-brgl@bgdev.pl
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pinctrl/qcom/pinctrl-msm.c | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+--- a/drivers/pinctrl/qcom/pinctrl-msm.c
++++ b/drivers/pinctrl/qcom/pinctrl-msm.c
+@@ -1036,6 +1036,25 @@ static bool msm_gpio_needs_dual_edge_par
+ test_bit(d->hwirq, pctrl->skip_wake_irqs);
+ }
+
++static void msm_gpio_irq_init_valid_mask(struct gpio_chip *gc,
++ unsigned long *valid_mask,
++ unsigned int ngpios)
++{
++ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
++ const struct msm_pingroup *g;
++ int i;
++
++ bitmap_fill(valid_mask, ngpios);
++
++ for (i = 0; i < ngpios; i++) {
++ g = &pctrl->soc->groups[i];
++
++ if (g->intr_detection_width != 1 &&
++ g->intr_detection_width != 2)
++ clear_bit(i, valid_mask);
++ }
++}
++
+ static int msm_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+ {
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+@@ -1439,6 +1458,7 @@ static int msm_gpio_init(struct msm_pinc
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_bad_irq;
+ girq->parents[0] = pctrl->irq;
++ girq->init_valid_mask = msm_gpio_irq_init_valid_mask;
+
+ ret = gpiochip_add_data(&pctrl->chip, pctrl);
+ if (ret) {
--- /dev/null
+From 9ee124caae1b0defd0e02c65686f539845a3ac9b Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@baylibre.com>
+Date: Fri, 4 Jul 2025 19:24:17 +0200
+Subject: pwm: Fix invalid state detection
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+
+commit 9ee124caae1b0defd0e02c65686f539845a3ac9b upstream.
+
+Commit 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid
+state") intended to allow some state transitions that were not allowed
+before. The idea is sane and back then I also got the code comment
+right, but the check for enabled is bogus. This resulted in state
+transitions for enabled states to be allowed to have invalid duty/period
+settings and thus it can happen that low-level drivers get requests for
+invalid states🙄.
+
+Invert the check to allow state transitions for disabled states only.
+
+Fixes: 9dd42d019e63 ("pwm: Allow pwm state transitions from an invalid state")
+Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+Link: https://lore.kernel.org/r/20250704172416.626433-2-u.kleine-koenig@baylibre.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pwm/core.c
++++ b/drivers/pwm/core.c
+@@ -549,7 +549,7 @@ static bool pwm_state_valid(const struct
+ * and supposed to be ignored. So also ignore any strange values and
+ * consider the state ok.
+ */
+- if (state->enabled)
++ if (!state->enabled)
+ return true;
+
+ if (!state->period)
--- /dev/null
+From 505b730ede7f5c4083ff212aa955155b5b92e574 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@baylibre.com>
+Date: Fri, 4 Jul 2025 19:27:27 +0200
+Subject: pwm: mediatek: Ensure to disable clocks in error path
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+
+commit 505b730ede7f5c4083ff212aa955155b5b92e574 upstream.
+
+After enabling the clocks each error path must disable the clocks again.
+One of them failed to do so. Unify the error paths to use goto to make it
+harder for future changes to add a similar bug.
+
+Fixes: 7ca59947b5fc ("pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()")
+Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
+Link: https://lore.kernel.org/r/20250704172728.626815-2-u.kleine-koenig@baylibre.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-mediatek.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/pwm/pwm-mediatek.c
++++ b/drivers/pwm/pwm-mediatek.c
+@@ -130,8 +130,10 @@ static int pwm_mediatek_config(struct pw
+ return ret;
+
+ clk_rate = clk_get_rate(pc->clk_pwms[pwm->hwpwm]);
+- if (!clk_rate)
+- return -EINVAL;
++ if (!clk_rate) {
++ ret = -EINVAL;
++ goto out;
++ }
+
+ /* Make sure we use the bus clock and not the 26MHz clock */
+ if (pc->soc->has_ck_26m_sel)
+@@ -150,9 +152,9 @@ static int pwm_mediatek_config(struct pw
+ }
+
+ if (clkdiv > PWM_CLK_DIV_MAX) {
+- pwm_mediatek_clk_disable(chip, pwm);
+ dev_err(pwmchip_parent(chip), "period of %d ns not supported\n", period_ns);
+- return -EINVAL;
++ ret = -EINVAL;
++ goto out;
+ }
+
+ if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) {
+@@ -169,9 +171,10 @@ static int pwm_mediatek_config(struct pw
+ pwm_mediatek_writel(pc, pwm->hwpwm, reg_width, cnt_period);
+ pwm_mediatek_writel(pc, pwm->hwpwm, reg_thres, cnt_duty);
+
++out:
+ pwm_mediatek_clk_disable(chip, pwm);
+
+- return 0;
++ return ret;
+ }
+
+ static int pwm_mediatek_enable(struct pwm_chip *chip, struct pwm_device *pwm)
--- /dev/null
+From 3ebb1b6522392f64902b4e96954e35927354aa27 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>
+Date: Thu, 26 Jun 2025 11:23:44 +0200
+Subject: sched: Fix preemption string of preempt_dynamic_none
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+
+commit 3ebb1b6522392f64902b4e96954e35927354aa27 upstream.
+
+Zero is a valid value for "preempt_dynamic_mode", namely
+"preempt_dynamic_none".
+
+Fix the off-by-one in preempt_model_str(), so that "preempty_dynamic_none"
+is correctly formatted as PREEMPT(none) instead of PREEMPT(undef).
+
+Fixes: 8bdc5daaa01e ("sched: Add a generic function to return the preemption string")
+Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20250626-preempt-str-none-v2-1-526213b70a89@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -7695,7 +7695,7 @@ const char *preempt_model_str(void)
+
+ if (IS_ENABLED(CONFIG_PREEMPT_DYNAMIC)) {
+ seq_buf_printf(&s, "(%s)%s",
+- preempt_dynamic_mode > 0 ?
++ preempt_dynamic_mode >= 0 ?
+ preempt_modes[preempt_dynamic_mode] : "undef",
+ brace ? "}" : "");
+ return seq_buf_str(&s);
crypto-s390-sha-fix-uninitialized-variable-in-sha-1-and-sha-2.patch
rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch
ipmi-msghandler-fix-potential-memory-corruption-in-ipmi_create_user.patch
+x86-mce-amd-add-default-names-for-mca-banks-and-blocks.patch
+x86-mce-amd-fix-threshold-limit-reset.patch
+x86-mce-don-t-remove-sysfs-if-thresholding-sysfs-init-fails.patch
+x86-mce-ensure-user-polling-settings-are-honored-when-restarting-timer.patch
+x86-mce-make-sure-cmci-banks-are-cleared-during-shutdown-on-intel.patch
+kvm-x86-xen-allow-out-of-range-event-channel-ports-in-irq-routing-table.patch
+kvm-x86-hyper-v-skip-non-canonical-addresses-during-pv-tlb-flush.patch
+kvm-svm-add-missing-member-in-snp_launch_start-command-structure.patch
+kvm-svm-reject-sev-es-intra-host-migration-if-vcpu-creation-is-in-flight.patch
+kvm-allow-cpu-to-reschedule-while-setting-per-page-memory-attributes.patch
+sched-fix-preemption-string-of-preempt_dynamic_none.patch
+alsa-ad1816a-fix-potential-null-pointer-deref-in-snd_card_ad1816a_pnp.patch
+alsa-hda-realtek-add-mute-led-support-for-hp-victus-15-fb2xxx.patch
+arm64-filter-out-sme-hwcaps-when-feat_sme-isn-t-implemented.patch
+asoc-fsl_sai-force-a-software-reset-when-starting-in-consumer-mode.patch
+io_uring-msg_ring-ensure-io_kiocb-freeing-is-deferred-for-rcu.patch
+gre-fix-ipv6-multicast-route-creation.patch
+net-ethernet-rtsn-fix-a-null-pointer-dereference-in-rtsn_probe.patch
+gpiolib-fix-performance-regression-when-using-gpio_chip_get_multiple.patch
+md-md-bitmap-fix-gpf-in-bitmap_get_stats.patch
+pinctrl-nuvoton-fix-boot-on-ma35dx-platforms.patch
+pinctrl-qcom-msm-mark-certain-pins-as-invalid-for-interrupts.patch
+pwm-fix-invalid-state-detection.patch
+pwm-mediatek-ensure-to-disable-clocks-in-error-path.patch
+wifi-prevent-a-msdu-attacks-in-mesh-networks.patch
+wifi-mwifiex-discard-erroneous-disassoc-frames-on-sta-interface.patch
+wifi-mt76-mt7921-prevent-decap-offload-config-before-sta-initialization.patch
+wifi-mt76-mt7925-prevent-null-pointer-dereference-in-mt7925_sta_set_decap_offload.patch
+wifi-mt76-mt7925-fix-the-wrong-config-for-tx-interrupt.patch
+wifi-mt76-mt7925-fix-invalid-array-index-in-ssid-assignment-during-hw-scan.patch
+drm-imagination-fix-kernel-crash-when-hard-resetting-the-gpu.patch
+drm-amdkfd-don-t-call-mmput-from-mmu-notifier-callback.patch
+drm-amdgpu-include-sdma_4_4_4.bin.patch
+drm-amdkfd-add-hqd_sdma_get_doorbell-callbacks-for-gfx7-8.patch
--- /dev/null
+From 7035a082348acf1d43ffb9ff735899f8e3863f8f Mon Sep 17 00:00:00 2001
+From: Deren Wu <deren.wu@mediatek.com>
+Date: Sun, 25 May 2025 14:11:22 +0800
+Subject: wifi: mt76: mt7921: prevent decap offload config before STA initialization
+
+From: Deren Wu <deren.wu@mediatek.com>
+
+commit 7035a082348acf1d43ffb9ff735899f8e3863f8f upstream.
+
+The decap offload configuration should only be applied after the STA has
+been successfully initialized. Attempting to configure it earlier can lead
+to corruption of the MAC configuration in the chip's hardware state.
+
+Add an early check for `msta->deflink.wcid.sta` to ensure the station peer
+is properly initialized before proceeding with decapsulation offload
+configuration.
+
+Cc: stable@vger.kernel.org
+Fixes: 24299fc869f7 ("mt76: mt7921: enable rx header traslation offload")
+Signed-off-by: Deren Wu <deren.wu@mediatek.com>
+Link: https://patch.msgid.link/f23a72ba7a3c1ad38ba9e13bb54ef21d6ef44ffb.1748149855.git.deren.wu@mediatek.com
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7921/main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
+@@ -1180,6 +1180,9 @@ static void mt7921_sta_set_decap_offload
+ struct mt792x_sta *msta = (struct mt792x_sta *)sta->drv_priv;
+ struct mt792x_dev *dev = mt792x_hw_dev(hw);
+
++ if (!msta->deflink.wcid.sta)
++ return;
++
+ mt792x_mutex_acquire(dev);
+
+ if (enabled)
--- /dev/null
+From c701574c54121af2720648572efbfe77564652d1 Mon Sep 17 00:00:00 2001
+From: Michael Lo <michael.lo@mediatek.com>
+Date: Thu, 12 Jun 2025 14:20:46 +0800
+Subject: wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scan
+
+From: Michael Lo <michael.lo@mediatek.com>
+
+commit c701574c54121af2720648572efbfe77564652d1 upstream.
+
+Update the destination index to use 'n_ssids', which is incremented only
+when a valid SSID is present. Previously, both mt76_connac_mcu_hw_scan()
+and mt7925_mcu_hw_scan() used the loop index 'i' for the destination
+array, potentially leaving gaps if any source SSIDs had zero length.
+
+Cc: stable@vger.kernel.org
+Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
+Signed-off-by: Michael Lo <michael.lo@mediatek.com>
+Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
+Link: https://patch.msgid.link/20250612062046.160598-1-mingyen.hsieh@mediatek.com
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 4 ++--
+ drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
++++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+@@ -1703,8 +1703,8 @@ int mt76_connac_mcu_hw_scan(struct mt76_
+ if (!sreq->ssids[i].ssid_len)
+ continue;
+
+- req->ssids[i].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len);
+- memcpy(req->ssids[i].ssid, sreq->ssids[i].ssid,
++ req->ssids[n_ssids].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len);
++ memcpy(req->ssids[n_ssids].ssid, sreq->ssids[i].ssid,
+ sreq->ssids[i].ssid_len);
+ n_ssids++;
+ }
+--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+@@ -2834,8 +2834,8 @@ int mt7925_mcu_hw_scan(struct mt76_phy *
+ if (!sreq->ssids[i].ssid_len)
+ continue;
+
+- ssid->ssids[i].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len);
+- memcpy(ssid->ssids[i].ssid, sreq->ssids[i].ssid,
++ ssid->ssids[n_ssids].ssid_len = cpu_to_le32(sreq->ssids[i].ssid_len);
++ memcpy(ssid->ssids[n_ssids].ssid, sreq->ssids[i].ssid,
+ sreq->ssids[i].ssid_len);
+ n_ssids++;
+ }
--- /dev/null
+From d20de55332e92f9e614c34783c00bb6ce2fec067 Mon Sep 17 00:00:00 2001
+From: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
+Date: Thu, 12 Jun 2025 14:09:31 +0800
+Subject: wifi: mt76: mt7925: fix the wrong config for tx interrupt
+
+From: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
+
+commit d20de55332e92f9e614c34783c00bb6ce2fec067 upstream.
+
+MT_INT_TX_DONE_MCU_WM may cause tx interrupt to be mishandled
+during a reset failure, leading to the reset process failing.
+By using MT_INT_TX_DONE_MCU instead of MT_INT_TX_DONE_MCU_WM,
+the handling of tx interrupt is improved.
+
+Cc: stable@vger.kernel.org
+Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
+Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
+Link: https://patch.msgid.link/20250612060931.135635-1-mingyen.hsieh@mediatek.com
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7925/regs.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7925/regs.h
++++ b/drivers/net/wireless/mediatek/mt76/mt7925/regs.h
+@@ -58,7 +58,7 @@
+
+ #define MT_INT_TX_DONE_MCU (MT_INT_TX_DONE_MCU_WM | \
+ MT_INT_TX_DONE_FWDL)
+-#define MT_INT_TX_DONE_ALL (MT_INT_TX_DONE_MCU_WM | \
++#define MT_INT_TX_DONE_ALL (MT_INT_TX_DONE_MCU | \
+ MT_INT_TX_DONE_BAND0 | \
+ GENMASK(18, 4))
+
--- /dev/null
+From 35ad47c0b3da04b00b19a8b9ed5632e2f2520472 Mon Sep 17 00:00:00 2001
+From: Deren Wu <deren.wu@mediatek.com>
+Date: Sun, 25 May 2025 14:11:21 +0800
+Subject: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()
+
+From: Deren Wu <deren.wu@mediatek.com>
+
+commit 35ad47c0b3da04b00b19a8b9ed5632e2f2520472 upstream.
+
+Add a NULL check for msta->vif before accessing its members to prevent
+a kernel panic in AP mode deployment. This also fix the issue reported
+in [1].
+
+The crash occurs when this function is triggered before the station is
+fully initialized. The call trace shows a page fault at
+mt7925_sta_set_decap_offload() due to accessing resources when msta->vif
+is NULL.
+
+Fix this by adding an early return if msta->vif is NULL and also check
+wcid.sta is ready. This ensures we only proceed with decap offload
+configuration when the station's state is properly initialized.
+
+[14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0
+[14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G
+[14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE
+[14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
+[14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]
+[14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common]
+[14739.851985] sp : ffffffc085efb500
+[14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158
+[14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001
+[14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88
+[14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000
+[14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080
+[14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000
+[14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0
+[14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100
+[14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000
+[14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8
+[14739.926686] Call trace:
+[14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]
+[14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211]
+[14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211]
+[14739.946860] sta_info_move_state+0x1c/0x30 [mac80211]
+[14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211]
+[14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211]
+[14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211]
+[14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211]
+[14739.975516] genl_family_rcv_msg_doit+0xdc/0x150
+[14739.980158] genl_rcv_msg+0x218/0x298
+[14739.983830] netlink_rcv_skb+0x64/0x138
+[14739.987670] genl_rcv+0x40/0x60
+[14739.990816] netlink_unicast+0x314/0x380
+[14739.994742] netlink_sendmsg+0x198/0x3f0
+[14739.998664] __sock_sendmsg+0x64/0xc0
+[14740.002324] ____sys_sendmsg+0x260/0x298
+[14740.006242] ___sys_sendmsg+0xb4/0x110
+
+Cc: stable@vger.kernel.org
+Link: https://github.com/morrownr/USB-WiFi/issues/603 [1]
+Fixes: b859ad65309a ("wifi: mt76: mt7925: add link handling in mt7925_sta_set_decap_offload")
+Signed-off-by: Deren Wu <deren.wu@mediatek.com>
+Link: https://patch.msgid.link/35aedbffa050e98939264300407a52ba4e236d52.1748149855.git.deren.wu@mediatek.com
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/mediatek/mt76/mt7925/main.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
++++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+@@ -1600,6 +1600,9 @@ static void mt7925_sta_set_decap_offload
+ unsigned long valid = mvif->valid_links;
+ u8 i;
+
++ if (!msta->vif)
++ return;
++
+ mt792x_mutex_acquire(dev);
+
+ valid = ieee80211_vif_is_mld(vif) ? mvif->valid_links : BIT(0);
+@@ -1614,6 +1617,9 @@ static void mt7925_sta_set_decap_offload
+ else
+ clear_bit(MT_WCID_FLAG_HDR_TRANS, &mlink->wcid.flags);
+
++ if (!mlink->wcid.sta)
++ continue;
++
+ mt7925_mcu_wtbl_update_hdr_trans(dev, vif, sta, i);
+ }
+
--- /dev/null
+From 3b602ddc0df723992721b0d286c90c9bdd755b34 Mon Sep 17 00:00:00 2001
+From: Vitor Soares <vitor.soares@toradex.com>
+Date: Tue, 1 Jul 2025 15:26:43 +0100
+Subject: wifi: mwifiex: discard erroneous disassoc frames on STA interface
+
+From: Vitor Soares <vitor.soares@toradex.com>
+
+commit 3b602ddc0df723992721b0d286c90c9bdd755b34 upstream.
+
+When operating in concurrent STA/AP mode with host MLME enabled,
+the firmware incorrectly sends disassociation frames to the STA
+interface when clients disconnect from the AP interface.
+This causes kernel warnings as the STA interface processes
+disconnect events that don't apply to it:
+
+[ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211]
+[ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us
+[ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT
+[ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)
+[ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]
+[ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211]
+[ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211]
+[ 1303.370221] sp : ffff800083053be0
+[ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000
+[ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae
+[ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008
+[ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006
+[ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048
+[ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000
+[ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300
+[ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002
+[ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186
+[ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de
+[ 1303.446221] Call trace:
+[ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P)
+[ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211]
+[ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex]
+[ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex]
+[ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex]
+[ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex]
+[ 1303.483734] process_one_work+0x14c/0x28c
+[ 1303.487845] worker_thread+0x2cc/0x3d4
+[ 1303.491680] kthread+0x12c/0x208
+[ 1303.495014] ret_from_fork+0x10/0x20
+
+Add validation in the STA receive path to verify that disassoc/deauth
+frames originate from the connected AP. Frames that fail this check
+are discarded early, preventing them from reaching the MLME layer and
+triggering WARN_ON().
+
+This filtering logic is similar with that used in the
+ieee80211_rx_mgmt_disassoc() function in mac80211, which drops
+disassoc frames that don't match the current BSSID
+(!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring
+only relevant frames are processed.
+
+Tested on:
+- 8997 with FW 16.68.1.p197
+
+Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
+Reviewed-by: Jeff Chen <jeff.chen_1@nxp.con>
+Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
+Link: https://patch.msgid.link/20250701142643.658990-1-ivitro@gmail.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/marvell/mwifiex/util.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/marvell/mwifiex/util.c
++++ b/drivers/net/wireless/marvell/mwifiex/util.c
+@@ -477,7 +477,9 @@ mwifiex_process_mgmt_packet(struct mwifi
+ "auth: receive authentication from %pM\n",
+ ieee_hdr->addr3);
+ } else {
+- if (!priv->wdev.connected)
++ if (!priv->wdev.connected ||
++ !ether_addr_equal(ieee_hdr->addr3,
++ priv->curr_bss_params.bss_descriptor.mac_address))
+ return 0;
+
+ if (ieee80211_is_deauth(ieee_hdr->frame_control)) {
--- /dev/null
+From 737bb912ebbe4571195c56eba557c4d7315b26fb Mon Sep 17 00:00:00 2001
+From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+Date: Mon, 16 Jun 2025 02:46:35 +0200
+Subject: wifi: prevent A-MSDU attacks in mesh networks
+
+From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+
+commit 737bb912ebbe4571195c56eba557c4d7315b26fb upstream.
+
+This patch is a mitigation to prevent the A-MSDU spoofing vulnerability
+for mesh networks. The initial update to the IEEE 802.11 standard, in
+response to the FragAttacks, missed this case (CVE-2025-27558). It can
+be considered a variant of CVE-2020-24588 but for mesh networks.
+
+This patch tries to detect if a standard MSDU was turned into an A-MSDU
+by an adversary. This is done by parsing a received A-MSDU as a standard
+MSDU, calculating the length of the Mesh Control header, and seeing if
+the 6 bytes after this header equal the start of an rfc1042 header. If
+equal, this is a strong indication of an ongoing attack attempt.
+
+This defense was tested with mac80211_hwsim against a mesh network that
+uses an empty Mesh Address Extension field, i.e., when four addresses
+are used, and when using a 12-byte Mesh Address Extension field, i.e.,
+when six addresses are used. Functionality of normal MSDUs and A-MSDUs
+was also tested, and confirmed working, when using both an empty and
+12-byte Mesh Address Extension field.
+
+It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh
+networks keep being detected and prevented.
+
+Note that the vulnerability being patched, and the defense being
+implemented, was also discussed in the following paper and in the
+following IEEE 802.11 presentation:
+
+https://papers.mathyvanhoef.com/wisec2025.pdf
+https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
+Link: https://patch.msgid.link/20250616004635.224344-1-Mathy.Vanhoef@kuleuven.be
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/wireless/util.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++--
+ 1 file changed, 50 insertions(+), 2 deletions(-)
+
+--- a/net/wireless/util.c
++++ b/net/wireless/util.c
+@@ -820,6 +820,52 @@ bool ieee80211_is_valid_amsdu(struct sk_
+ }
+ EXPORT_SYMBOL(ieee80211_is_valid_amsdu);
+
++
++/*
++ * Detects if an MSDU frame was maliciously converted into an A-MSDU
++ * frame by an adversary. This is done by parsing the received frame
++ * as if it were a regular MSDU, even though the A-MSDU flag is set.
++ *
++ * For non-mesh interfaces, detection involves checking whether the
++ * payload, when interpreted as an MSDU, begins with a valid RFC1042
++ * header. This is done by comparing the A-MSDU subheader's destination
++ * address to the start of the RFC1042 header.
++ *
++ * For mesh interfaces, the MSDU includes a 6-byte Mesh Control field
++ * and an optional variable-length Mesh Address Extension field before
++ * the RFC1042 header. The position of the RFC1042 header must therefore
++ * be calculated based on the mesh header length.
++ *
++ * Since this function intentionally parses an A-MSDU frame as an MSDU,
++ * it only assumes that the A-MSDU subframe header is present, and
++ * beyond this it performs its own bounds checks under the assumption
++ * that the frame is instead parsed as a non-aggregated MSDU.
++ */
++static bool
++is_amsdu_aggregation_attack(struct ethhdr *eth, struct sk_buff *skb,
++ enum nl80211_iftype iftype)
++{
++ int offset;
++
++ /* Non-mesh case can be directly compared */
++ if (iftype != NL80211_IFTYPE_MESH_POINT)
++ return ether_addr_equal(eth->h_dest, rfc1042_header);
++
++ offset = __ieee80211_get_mesh_hdrlen(eth->h_dest[0]);
++ if (offset == 6) {
++ /* Mesh case with empty address extension field */
++ return ether_addr_equal(eth->h_source, rfc1042_header);
++ } else if (offset + ETH_ALEN <= skb->len) {
++ /* Mesh case with non-empty address extension field */
++ u8 temp[ETH_ALEN];
++
++ skb_copy_bits(skb, offset, temp, ETH_ALEN);
++ return ether_addr_equal(temp, rfc1042_header);
++ }
++
++ return false;
++}
++
+ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
+ const u8 *addr, enum nl80211_iftype iftype,
+ const unsigned int extra_headroom,
+@@ -861,8 +907,10 @@ void ieee80211_amsdu_to_8023s(struct sk_
+ /* the last MSDU has no padding */
+ if (subframe_len > remaining)
+ goto purge;
+- /* mitigate A-MSDU aggregation injection attacks */
+- if (ether_addr_equal(hdr.eth.h_dest, rfc1042_header))
++ /* mitigate A-MSDU aggregation injection attacks, to be
++ * checked when processing first subframe (offset == 0).
++ */
++ if (offset == 0 && is_amsdu_aggregation_attack(&hdr.eth, skb, iftype))
+ goto purge;
+
+ offset += sizeof(struct ethhdr);
--- /dev/null
+From d66e1e90b16055d2f0ee76e5384e3f119c3c2773 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:58 +0000
+Subject: x86/mce/amd: Add default names for MCA banks and blocks
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+commit d66e1e90b16055d2f0ee76e5384e3f119c3c2773 upstream.
+
+Ensure that sysfs init doesn't fail for new/unrecognized bank types or if
+a bank has additional blocks available.
+
+Most MCA banks have a single thresholding block, so the block takes the same
+name as the bank.
+
+Unified Memory Controllers (UMCs) are a special case where there are two
+blocks and each has a unique name.
+
+However, the microarchitecture allows for five blocks. Any new MCA bank types
+with more than one block will be missing names for the extra blocks. The MCE
+sysfs will fail to initialize in this case.
+
+Fixes: 87a6d4091bd7 ("x86/mce/AMD: Update sysfs bank names for SMCA systems")
+Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-3-236dd74f645f@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/amd.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mce/amd.c
++++ b/arch/x86/kernel/cpu/mce/amd.c
+@@ -1113,13 +1113,20 @@ static const char *get_name(unsigned int
+ }
+
+ bank_type = smca_get_bank_type(cpu, bank);
+- if (bank_type >= N_SMCA_BANK_TYPES)
+- return NULL;
+
+ if (b && (bank_type == SMCA_UMC || bank_type == SMCA_UMC_V2)) {
+ if (b->block < ARRAY_SIZE(smca_umc_block_names))
+ return smca_umc_block_names[b->block];
+- return NULL;
++ }
++
++ if (b && b->block) {
++ snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_block_%u", b->block);
++ return buf_mcatype;
++ }
++
++ if (bank_type >= N_SMCA_BANK_TYPES) {
++ snprintf(buf_mcatype, MAX_MCATYPE_NAME_LEN, "th_bank_%u", bank);
++ return buf_mcatype;
+ }
+
+ if (per_cpu(smca_bank_counts, cpu)[bank_type] == 1)
--- /dev/null
+From 5f6e3b720694ad771911f637a51930f511427ce1 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:59 +0000
+Subject: x86/mce/amd: Fix threshold limit reset
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+commit 5f6e3b720694ad771911f637a51930f511427ce1 upstream.
+
+The MCA threshold limit must be reset after servicing the interrupt.
+
+Currently, the restart function doesn't have an explicit check for this. It
+makes some assumptions based on the current limit and what's in the registers.
+These assumptions don't always hold, so the limit won't be reset in some
+cases.
+
+Make the reset condition explicit. Either an interrupt/overflow has occurred
+or the bank is being initialized.
+
+Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-4-236dd74f645f@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/amd.c | 15 +++++++--------
+ 1 file changed, 7 insertions(+), 8 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mce/amd.c
++++ b/arch/x86/kernel/cpu/mce/amd.c
+@@ -350,7 +350,6 @@ static void smca_configure(unsigned int
+
+ struct thresh_restart {
+ struct threshold_block *b;
+- int reset;
+ int set_lvt_off;
+ int lvt_off;
+ u16 old_limit;
+@@ -432,13 +431,13 @@ static void threshold_restart_bank(void
+
+ rdmsr(tr->b->address, lo, hi);
+
+- if (tr->b->threshold_limit < (hi & THRESHOLD_MAX))
+- tr->reset = 1; /* limit cannot be lower than err count */
+-
+- if (tr->reset) { /* reset err count and overflow bit */
+- hi =
+- (hi & ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI)) |
+- (THRESHOLD_MAX - tr->b->threshold_limit);
++ /*
++ * Reset error count and overflow bit.
++ * This is done during init or after handling an interrupt.
++ */
++ if (hi & MASK_OVERFLOW_HI || tr->set_lvt_off) {
++ hi &= ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI);
++ hi |= THRESHOLD_MAX - tr->b->threshold_limit;
+ } else if (tr->old_limit) { /* change limit w/o reset */
+ int new_count = (hi & THRESHOLD_MAX) +
+ (tr->old_limit - tr->b->threshold_limit);
--- /dev/null
+From 4c113a5b28bfd589e2010b5fc8867578b0135ed7 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:56 +0000
+Subject: x86/mce: Don't remove sysfs if thresholding sysfs init fails
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+commit 4c113a5b28bfd589e2010b5fc8867578b0135ed7 upstream.
+
+Currently, the MCE subsystem sysfs interface will be removed if the
+thresholding sysfs interface fails to be created. A common failure is due to
+new MCA bank types that are not recognized and don't have a short name set.
+
+The MCA thresholding feature is optional and should not break the common MCE
+sysfs interface. Also, new MCA bank types are occasionally introduced, and
+updates will be needed to recognize them. But likewise, this should not break
+the common sysfs interface.
+
+Keep the MCE sysfs interface regardless of the status of the thresholding
+sysfs interface.
+
+Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+Reviewed-by: Tony Luck <tony.luck@intel.com>
+Tested-by: Tony Luck <tony.luck@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-1-236dd74f645f@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/core.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mce/core.c
++++ b/arch/x86/kernel/cpu/mce/core.c
+@@ -2801,15 +2801,9 @@ static int mce_cpu_dead(unsigned int cpu
+ static int mce_cpu_online(unsigned int cpu)
+ {
+ struct timer_list *t = this_cpu_ptr(&mce_timer);
+- int ret;
+
+ mce_device_create(cpu);
+-
+- ret = mce_threshold_create_device(cpu);
+- if (ret) {
+- mce_device_remove(cpu);
+- return ret;
+- }
++ mce_threshold_create_device(cpu);
+ mce_reenable_cpu();
+ mce_start_timer(t);
+ return 0;
--- /dev/null
+From 00c092de6f28ebd32208aef83b02d61af2229b60 Mon Sep 17 00:00:00 2001
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+Date: Tue, 24 Jun 2025 14:15:57 +0000
+Subject: x86/mce: Ensure user polling settings are honored when restarting timer
+
+From: Yazen Ghannam <yazen.ghannam@amd.com>
+
+commit 00c092de6f28ebd32208aef83b02d61af2229b60 upstream.
+
+Users can disable MCA polling by setting the "ignore_ce" parameter or by
+setting "check_interval=0". This tells the kernel to *not* start the MCE
+timer on a CPU.
+
+If the user did not disable CMCI, then storms can occur. When these
+happen, the MCE timer will be started with a fixed interval. After the
+storm subsides, the timer's next interval is set to check_interval.
+
+This disregards the user's input through "ignore_ce" and
+"check_interval". Furthermore, if "check_interval=0", then the new timer
+will run faster than expected.
+
+Create a new helper to check these conditions and use it when a CMCI
+storm ends.
+
+ [ bp: Massage. ]
+
+Fixes: 7eae17c4add5 ("x86/mce: Add per-bank CMCI storm mitigation")
+Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/20250624-wip-mca-updates-v4-2-236dd74f645f@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/core.c | 16 ++++++++++------
+ 1 file changed, 10 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/cpu/mce/core.c
++++ b/arch/x86/kernel/cpu/mce/core.c
+@@ -1740,6 +1740,11 @@ static void mc_poll_banks_default(void)
+
+ void (*mc_poll_banks)(void) = mc_poll_banks_default;
+
++static bool should_enable_timer(unsigned long iv)
++{
++ return !mca_cfg.ignore_ce && iv;
++}
++
+ static void mce_timer_fn(struct timer_list *t)
+ {
+ struct timer_list *cpu_t = this_cpu_ptr(&mce_timer);
+@@ -1763,7 +1768,7 @@ static void mce_timer_fn(struct timer_li
+
+ if (mce_get_storm_mode()) {
+ __start_timer(t, HZ);
+- } else {
++ } else if (should_enable_timer(iv)) {
+ __this_cpu_write(mce_next_interval, iv);
+ __start_timer(t, iv);
+ }
+@@ -2156,11 +2161,10 @@ static void mce_start_timer(struct timer
+ {
+ unsigned long iv = check_interval * HZ;
+
+- if (mca_cfg.ignore_ce || !iv)
+- return;
+-
+- this_cpu_write(mce_next_interval, iv);
+- __start_timer(t, iv);
++ if (should_enable_timer(iv)) {
++ this_cpu_write(mce_next_interval, iv);
++ __start_timer(t, iv);
++ }
+ }
+
+ static void __mcheck_cpu_setup_timer(void)
--- /dev/null
+From 30ad231a5029bfa16e46ce868497b1a5cdd3c24d Mon Sep 17 00:00:00 2001
+From: JP Kobryn <inwardvessel@gmail.com>
+Date: Fri, 27 Jun 2025 10:49:35 -0700
+Subject: x86/mce: Make sure CMCI banks are cleared during shutdown on Intel
+
+From: JP Kobryn <inwardvessel@gmail.com>
+
+commit 30ad231a5029bfa16e46ce868497b1a5cdd3c24d upstream.
+
+CMCI banks are not cleared during shutdown on Intel CPUs. As a side effect,
+when a kexec is performed, CPUs coming back online are unable to
+rediscover/claim these occupied banks which breaks MCE reporting.
+
+Clear the CPU ownership during shutdown via cmci_clear() so the banks can
+be reclaimed and MCE reporting will become functional once more.
+
+ [ bp: Massage commit message. ]
+
+Reported-by: Aijay Adams <aijay@meta.com>
+Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Tony Luck <tony.luck@intel.com>
+Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/20250627174935.95194-1-inwardvessel@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/mce/intel.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/cpu/mce/intel.c
++++ b/arch/x86/kernel/cpu/mce/intel.c
+@@ -478,6 +478,7 @@ void mce_intel_feature_init(struct cpuin
+ void mce_intel_feature_clear(struct cpuinfo_x86 *c)
+ {
+ intel_clear_lmce();
++ cmci_clear();
+ }
+
+ bool intel_filter_mce(struct mce *m)
projects / thirdparty / kernel / stable-queue.git / commitdiff
