--- /dev/null
+From 3cd59d8ef8df7d7a079f54d56502dae8f716b39b Mon Sep 17 00:00:00 2001
+From: Dirk Su <dirk.su@canonical.com>
+Date: Wed, 26 Jun 2024 10:14:36 +0800
+Subject: ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook 645/665 G11.
+
+From: Dirk Su <dirk.su@canonical.com>
+
+commit 3cd59d8ef8df7d7a079f54d56502dae8f716b39b upstream.
+
+HP EliteBook 645/665 G11 needs ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to
+make mic-mute/audio-mute working.
+
+Signed-off-by: Dirk Su <dirk.su@canonical.com>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20240626021437.77039-1-dirk.su@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -10187,6 +10187,9 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x103c, 0x8c7c, "HP ProBook 445 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c7d, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c7e, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c7f, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c80, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
++ SND_PCI_QUIRK(0x103c, 0x8c81, "HP EliteBook 665 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
+ SND_PCI_QUIRK(0x103c, 0x8c89, "HP ProBook 460 G11", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8c8a, "HP EliteBook 630", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x8c8c, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED),
--- /dev/null
+From b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Tue, 11 Jun 2024 17:17:30 +0900
+Subject: btrfs: zoned: fix initial free space detection
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a upstream.
+
+When creating a new block group, it calls btrfs_add_new_free_space() to add
+the entire block group range into the free space accounting.
+__btrfs_add_free_space_zoned() checks if size == block_group->length to
+detect the initial free space adding, and proceed that case properly.
+
+However, if the zone_capacity == zone_size and the over-write speed is fast
+enough, the entire zone can be over-written within one transaction. That
+confuses __btrfs_add_free_space_zoned() to handle it as an initial free
+space accounting. As a result, that block group becomes a strange state: 0
+used bytes, 0 zone_unusable bytes, but alloc_offset == zone_capacity (no
+allocation anymore).
+
+The initial free space accounting can properly be checked by checking
+alloc_offset too.
+
+Fixes: 98173255bddd ("btrfs: zoned: calculate free space from zone capacity")
+CC: stable@vger.kernel.org # 6.1+
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/free-space-cache.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/free-space-cache.c
++++ b/fs/btrfs/free-space-cache.c
+@@ -2697,7 +2697,7 @@ static int __btrfs_add_free_space_zoned(
+ u64 offset = bytenr - block_group->start;
+ u64 to_free, to_unusable;
+ int bg_reclaim_threshold = 0;
+- bool initial = (size == block_group->length);
++ bool initial = ((size == block_group->length) && (block_group->alloc_offset == 0));
+ u64 reclaimable_unusable;
+
+ WARN_ON(!initial && offset + size > block_group->zone_capacity);
--- /dev/null
+From 6ef8eb5125722c241fd60d7b0c872d5c2e5dd4ca Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Tue, 18 Jun 2024 16:13:36 +0800
+Subject: cpu: Fix broken cmdline "nosmp" and "maxcpus=0"
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 6ef8eb5125722c241fd60d7b0c872d5c2e5dd4ca upstream.
+
+After the rework of "Parallel CPU bringup", the cmdline "nosmp" and
+"maxcpus=0" parameters are not working anymore. These parameters set
+setup_max_cpus to zero and that's handed to bringup_nonboot_cpus().
+
+The code there does a decrement before checking for zero, which brings it
+into the negative space and brings up all CPUs.
+
+Add a zero check at the beginning of the function to prevent this.
+
+[ tglx: Massaged change log ]
+
+Fixes: 18415f33e2ac4ab382 ("cpu/hotplug: Allow "parallel" bringup up to CPUHP_BP_KICK_AP_STATE")
+Fixes: 06c6796e0304234da6 ("cpu/hotplug: Fix off by one in cpuhp_bringup_mask()")
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240618081336.3996825-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cpu.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/cpu.c
++++ b/kernel/cpu.c
+@@ -1859,6 +1859,9 @@ static inline bool cpuhp_bringup_cpus_pa
+
+ void __init bringup_nonboot_cpus(unsigned int max_cpus)
+ {
++ if (!max_cpus)
++ return;
++
+ /* Try parallel bringup optimization if enabled */
+ if (cpuhp_bringup_cpus_parallel(max_cpus))
+ return;
--- /dev/null
+From 932d8476399f622aa0767a4a0a9e78e5341dc0e1 Mon Sep 17 00:00:00 2001
+From: Yuntao Wang <ytcoode@gmail.com>
+Date: Wed, 15 May 2024 21:45:54 +0800
+Subject: cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked()
+
+From: Yuntao Wang <ytcoode@gmail.com>
+
+commit 932d8476399f622aa0767a4a0a9e78e5341dc0e1 upstream.
+
+Commit 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare
+stage") added a dynamic range for the prepare states, but did not handle
+the assignment of the dynstate variable in __cpuhp_setup_state_cpuslocked().
+
+This causes the corresponding startup callback not to be invoked when
+calling __cpuhp_setup_state_cpuslocked() with the CPUHP_BP_PREPARE_DYN
+parameter, even though it should be.
+
+Currently, the users of __cpuhp_setup_state_cpuslocked(), for one reason or
+another, have not triggered this bug.
+
+Fixes: 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare stage")
+Signed-off-by: Yuntao Wang <ytcoode@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240515134554.427071-1-ytcoode@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/cpu.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/kernel/cpu.c
++++ b/kernel/cpu.c
+@@ -2449,7 +2449,7 @@ EXPORT_SYMBOL_GPL(__cpuhp_state_add_inst
+ * The caller needs to hold cpus read locked while calling this function.
+ * Return:
+ * On success:
+- * Positive state number if @state is CPUHP_AP_ONLINE_DYN;
++ * Positive state number if @state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN;
+ * 0 for all other states
+ * On failure: proper (negative) error code
+ */
+@@ -2472,7 +2472,7 @@ int __cpuhp_setup_state_cpuslocked(enum
+ ret = cpuhp_store_callbacks(state, name, startup, teardown,
+ multi_instance);
+
+- dynstate = state == CPUHP_AP_ONLINE_DYN;
++ dynstate = state == CPUHP_AP_ONLINE_DYN || state == CPUHP_BP_PREPARE_DYN;
+ if (ret > 0 && dynstate) {
+ state = ret;
+ ret = 0;
+@@ -2503,8 +2503,8 @@ int __cpuhp_setup_state_cpuslocked(enum
+ out:
+ mutex_unlock(&cpuhp_state_mutex);
+ /*
+- * If the requested state is CPUHP_AP_ONLINE_DYN, return the
+- * dynamically allocated state in case of success.
++ * If the requested state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN,
++ * return the dynamically allocated state in case of success.
+ */
+ if (!ret && dynstate)
+ return state;
--- /dev/null
+From a1ff59784b277795a613beaa5d3dd9c5595c69a7 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 20 Jun 2024 18:14:53 +0200
+Subject: cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit a1ff59784b277795a613beaa5d3dd9c5595c69a7 upstream.
+
+It is reported that single-thread performance on some hybrid systems
+dropped significantly after commit 7feec7430edd ("ACPI: CPPC: Only probe
+for _CPC if CPPC v2 is acked") which prevented _CPC from being used if
+the support for it had not been confirmed by the platform firmware.
+
+The problem is that if the platform firmware does not confirm CPPC v2
+support, cppc_get_perf_caps() returns an error which prevents the
+intel_pstate driver from enabling ITMT. Consequently, the scheduler
+does not get any hints on CPU performance differences, so in a hybrid
+system some tasks may run on CPUs with lower capacity even though they
+should be running on high-capacity CPUs.
+
+To address this, modify intel_pstate to use the information from
+MSR_HWP_CAPABILITIES to enable ITMT if CPPC is not available (which is
+done already if the highest performance number coming from CPPC is not
+realistic).
+
+Fixes: 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked")
+Closes: https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@kfocus.org
+Link: https://lore.kernel.org/linux-acpi/ZnD22b3Br1ng7alf@kf-XE
+Reported-by: Aaron Rainbolt <arainbolt@kfocus.org>
+Tested-by: Aaron Rainbolt <arainbolt@kfocus.org>
+Cc: 5.19+ <stable@vger.kernel.org> # 5.19+
+Link: https://patch.msgid.link/12460110.O9o76ZdvQC@rjwysocki.net
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/intel_pstate.c | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -357,15 +357,14 @@ static void intel_pstate_set_itmt_prio(i
+ int ret;
+
+ ret = cppc_get_perf_caps(cpu, &cppc_perf);
+- if (ret)
+- return;
+-
+ /*
+- * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff.
+- * In this case we can't use CPPC.highest_perf to enable ITMT.
+- * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide.
++ * If CPPC is not available, fall back to MSR_HWP_CAPABILITIES bits [8:0].
++ *
++ * Also, on some systems with overclocking enabled, CPPC.highest_perf is
++ * hardcoded to 0xff, so CPPC.highest_perf cannot be used to enable ITMT.
++ * Fall back to MSR_HWP_CAPABILITIES then too.
+ */
+- if (cppc_perf.highest_perf == CPPC_MAX_PERF)
++ if (ret || cppc_perf.highest_perf == CPPC_MAX_PERF)
+ cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached));
+
+ /*
--- /dev/null
+From 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 14 Jun 2024 09:54:20 +0200
+Subject: csky, hexagon: fix broken sys_sync_file_range
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff upstream.
+
+Both of these architectures require u64 function arguments to be
+passed in even/odd pairs of registers or stack slots, which in case of
+sync_file_range would result in a seven-argument system call that is
+not currently possible. The system call is therefore incompatible with
+all existing binaries.
+
+While it would be possible to implement support for seven arguments
+like on mips, it seems better to use a six-argument version, either
+with the normal argument order but misaligned as on most architectures
+or with the reordered sync_file_range2() calling conventions as on
+arm and powerpc.
+
+Cc: stable@vger.kernel.org
+Acked-by: Guo Ren <guoren@kernel.org>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/csky/include/uapi/asm/unistd.h | 1 +
+ arch/hexagon/include/uapi/asm/unistd.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/arch/csky/include/uapi/asm/unistd.h
++++ b/arch/csky/include/uapi/asm/unistd.h
+@@ -6,6 +6,7 @@
+ #define __ARCH_WANT_SYS_CLONE3
+ #define __ARCH_WANT_SET_GET_RLIMIT
+ #define __ARCH_WANT_TIME32_SYSCALLS
++#define __ARCH_WANT_SYNC_FILE_RANGE2
+ #include <asm-generic/unistd.h>
+
+ #define __NR_set_thread_area (__NR_arch_specific_syscall + 0)
+--- a/arch/hexagon/include/uapi/asm/unistd.h
++++ b/arch/hexagon/include/uapi/asm/unistd.h
+@@ -36,5 +36,6 @@
+ #define __ARCH_WANT_SYS_VFORK
+ #define __ARCH_WANT_SYS_FORK
+ #define __ARCH_WANT_TIME32_SYSCALLS
++#define __ARCH_WANT_SYNC_FILE_RANGE2
+
+ #include <asm-generic/unistd.h>
--- /dev/null
+From 2ec6c7f802332d1eff16f03e7c757f1543ee1183 Mon Sep 17 00:00:00 2001
+From: Michael Strauss <michael.strauss@amd.com>
+Date: Tue, 28 Nov 2023 10:31:12 -0500
+Subject: drm/amd/display: Send DP_TOTAL_LTTPR_CNT during detection if LTTPR is present
+
+From: Michael Strauss <michael.strauss@amd.com>
+
+commit 2ec6c7f802332d1eff16f03e7c757f1543ee1183 upstream.
+
+[WHY]
+New register field added in DP2.1 SCR, needed for auxless ALPM
+
+[HOW]
+Echo value read from 0xF0007 back to sink
+
+Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
+Cc: Mario Limonciello <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Alex Hung <alex.hung@amd.com>
+Signed-off-by: Michael Strauss <michael.strauss@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 10 +++++++++-
+ drivers/gpu/drm/amd/display/include/dpcd_defs.h | 5 +++++
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
++++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
+@@ -1590,9 +1590,17 @@ static bool retrieve_link_cap(struct dc_
+ return false;
+ }
+
+- if (dp_is_lttpr_present(link))
++ if (dp_is_lttpr_present(link)) {
+ configure_lttpr_mode_transparent(link);
+
++ // Echo TOTAL_LTTPR_CNT back downstream
++ core_link_write_dpcd(
++ link,
++ DP_TOTAL_LTTPR_CNT,
++ &link->dpcd_caps.lttpr_caps.phy_repeater_cnt,
++ sizeof(link->dpcd_caps.lttpr_caps.phy_repeater_cnt));
++ }
++
+ /* Read DP tunneling information. */
+ status = dpcd_get_tunneling_device_data(link);
+
+--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h
++++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h
+@@ -177,4 +177,9 @@ enum dpcd_psr_sink_states {
+ #define DP_SINK_PR_PIXEL_DEVIATION_PER_LINE 0x379
+ #define DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE 0x37A
+
++/* Remove once drm_dp_helper.h is updated upstream */
++#ifndef DP_TOTAL_LTTPR_CNT
++#define DP_TOTAL_LTTPR_CNT 0xF000A /* 2.1 */
++#endif
++
+ #endif /* __DAL_DPCD_DEFS_H__ */
--- /dev/null
+From f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 14 Jun 2024 13:48:26 -0400
+Subject: drm/amdgpu/atomfirmware: fix parsing of vram_info
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 upstream.
+
+v3.x changed the how vram width was encoded. The previous
+implementation actually worked correctly for most boards.
+Fix the implementation to work correctly everywhere.
+
+This fixes the vram width reported in the kernel log on
+some boards.
+
+Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c
+@@ -399,7 +399,7 @@ amdgpu_atomfirmware_get_vram_info(struct
+ mem_channel_number = vram_info->v30.channel_num;
+ mem_channel_width = vram_info->v30.channel_width;
+ if (vram_width)
+- *vram_width = mem_channel_number * (1 << mem_channel_width);
++ *vram_width = mem_channel_number * 16;
+ break;
+ default:
+ return -EINVAL;
--- /dev/null
+From bcfa48ff785bd121316592b131ff6531e3e696bb Mon Sep 17 00:00:00 2001
+From: Julia Zhang <julia.zhang@amd.com>
+Date: Mon, 3 Jun 2024 19:31:09 +0800
+Subject: drm/amdgpu: avoid using null object of framebuffer
+
+From: Julia Zhang <julia.zhang@amd.com>
+
+commit bcfa48ff785bd121316592b131ff6531e3e696bb upstream.
+
+Instead of using state->fb->obj[0] directly, get object from framebuffer
+by calling drm_gem_fb_get_obj() and return error code when object is
+null to avoid using null object of framebuffer.
+
+Reported-by: Fusheng Huang <fusheng.huang@ecarxgroup.com>
+Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
+Reviewed-by: Huang Rui <ray.huang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 18 ++++++++++++++++--
+ 1 file changed, 16 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+@@ -3,6 +3,7 @@
+ #include <drm/drm_atomic_helper.h>
+ #include <drm/drm_edid.h>
+ #include <drm/drm_simple_kms_helper.h>
++#include <drm/drm_gem_framebuffer_helper.h>
+ #include <drm/drm_vblank.h>
+
+ #include "amdgpu.h"
+@@ -314,7 +315,13 @@ static int amdgpu_vkms_prepare_fb(struct
+ return 0;
+ }
+ afb = to_amdgpu_framebuffer(new_state->fb);
+- obj = new_state->fb->obj[0];
++
++ obj = drm_gem_fb_get_obj(new_state->fb, 0);
++ if (!obj) {
++ DRM_ERROR("Failed to get obj from framebuffer\n");
++ return -EINVAL;
++ }
++
+ rbo = gem_to_amdgpu_bo(obj);
+ adev = amdgpu_ttm_adev(rbo->tbo.bdev);
+
+@@ -368,12 +375,19 @@ static void amdgpu_vkms_cleanup_fb(struc
+ struct drm_plane_state *old_state)
+ {
+ struct amdgpu_bo *rbo;
++ struct drm_gem_object *obj;
+ int r;
+
+ if (!old_state->fb)
+ return;
+
+- rbo = gem_to_amdgpu_bo(old_state->fb->obj[0]);
++ obj = drm_gem_fb_get_obj(old_state->fb, 0);
++ if (!obj) {
++ DRM_ERROR("Failed to get obj from framebuffer\n");
++ return;
++ }
++
++ rbo = gem_to_amdgpu_bo(obj);
+ r = amdgpu_bo_reserve(rbo, false);
+ if (unlikely(r)) {
+ DRM_ERROR("failed to reserve rbo before unpin\n");
--- /dev/null
+From 4f2a129b33a2054e62273edd5a051c34c08d96e9 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Thu, 27 Jun 2024 11:26:00 +1000
+Subject: drm/drm_file: Fix pid refcounting race
+
+From: Jann Horn <jannh@google.com>
+
+commit 4f2a129b33a2054e62273edd5a051c34c08d96e9 upstream.
+
+<maarten.lankhorst@linux.intel.com>, Maxime Ripard
+<mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>
+
+filp->pid is supposed to be a refcounted pointer; however, before this
+patch, drm_file_update_pid() only increments the refcount of a struct
+pid after storing a pointer to it in filp->pid and dropping the
+dev->filelist_mutex, making the following race possible:
+
+process A process B
+========= =========
+ begin drm_file_update_pid
+ mutex_lock(&dev->filelist_mutex)
+ rcu_replace_pointer(filp->pid, <pid B>, 1)
+ mutex_unlock(&dev->filelist_mutex)
+begin drm_file_update_pid
+mutex_lock(&dev->filelist_mutex)
+rcu_replace_pointer(filp->pid, <pid A>, 1)
+mutex_unlock(&dev->filelist_mutex)
+get_pid(<pid A>)
+synchronize_rcu()
+put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here ***
+ get_pid(<pid B>) *** UAF ***
+ synchronize_rcu()
+ put_pid(<pid A>)
+
+As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y
+because it requires RCU to detect a quiescent state in code that is not
+explicitly calling into the scheduler.
+
+This race leads to use-after-free of a "struct pid".
+It is probably somewhat hard to hit because process A has to pass
+through a synchronize_rcu() operation while process B is between
+mutex_unlock() and get_pid().
+
+Fix it by ensuring that by the time a pointer to the current task's pid
+is stored in the file, an extra reference to the pid has been taken.
+
+This fix also removes the condition for synchronize_rcu(); I think
+that optimization is unnecessary complexity, since in that case we
+would usually have bailed out on the lockless check above.
+
+Fixes: 1c7a387ffef8 ("drm: Update file owner during use")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_file.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/drm_file.c
++++ b/drivers/gpu/drm/drm_file.c
+@@ -469,14 +469,12 @@ void drm_file_update_pid(struct drm_file
+
+ dev = filp->minor->dev;
+ mutex_lock(&dev->filelist_mutex);
++ get_pid(pid);
+ old = rcu_replace_pointer(filp->pid, pid, 1);
+ mutex_unlock(&dev->filelist_mutex);
+
+- if (pid != old) {
+- get_pid(pid);
+- synchronize_rcu();
+- put_pid(old);
+- }
++ synchronize_rcu();
++ put_pid(old);
+ }
+
+ /**
--- /dev/null
+From d92a7580392ad4681b1d4f9275d00b95375ebe01 Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Mon, 17 Jun 2024 17:26:37 +0200
+Subject: drm/fbdev-dma: Only set smem_start is enable per module option
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit d92a7580392ad4681b1d4f9275d00b95375ebe01 upstream.
+
+Only export struct fb_info.fix.smem_start if that is required by the
+user and the memory does not come from vmalloc().
+
+Setting struct fb_info.fix.smem_start breaks systems where DMA
+memory is backed by vmalloc address space. An example error is
+shown below.
+
+[ 3.536043] ------------[ cut here ]------------
+[ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)
+[ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98
+[ 3.565455] Modules linked in:
+[ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250
+[ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
+[ 3.582452] Workqueue: events_unbound deferred_probe_work_func
+[ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+[ 3.595233] pc : __virt_to_phys+0x68/0x98
+[ 3.599246] lr : __virt_to_phys+0x68/0x98
+[ 3.603276] sp : ffff800083603990
+[ 3.677939] Call trace:
+[ 3.680393] __virt_to_phys+0x68/0x98
+[ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238
+[ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
+[ 3.695385] drm_fb_helper_initial_config+0x4c/0x68
+[ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0
+[ 3.705161] drm_client_register+0x60/0xb0
+[ 3.709269] drm_fbdev_dma_setup+0x94/0x148
+
+Additionally, DMA memory is assumed to by contiguous in physical
+address space, which is not guaranteed by vmalloc().
+
+Resolve this by checking the module flag drm_leak_fbdev_smem when
+DRM allocated the instance of struct fb_info. Fbdev-dma then only
+sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also
+guarantee that the framebuffer is not located in vmalloc address
+space.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Reported-by: Peng Fan (OSS) <peng.fan@oss.nxp.com>
+Closes: https://lore.kernel.org/dri-devel/20240604080328.4024838-1-peng.fan@oss.nxp.com/
+Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Closes: https://lore.kernel.org/dri-devel/CAMuHMdX3N0szUvt1VTbroa2zrT1Nye_VzPb5qqCZ7z5gSm7HGw@mail.gmail.com/
+Fixes: a51c7663f144 ("drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM")
+Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: <stable@vger.kernel.org> # v6.4+
+Link: https://patchwork.freedesktop.org/patch/msgid/20240617152843.11886-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_fb_helper.c | 6 +++---
+ drivers/gpu/drm/drm_fbdev_dma.c | 5 ++++-
+ 2 files changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/drm_fb_helper.c
++++ b/drivers/gpu/drm/drm_fb_helper.c
+@@ -524,6 +524,9 @@ struct fb_info *drm_fb_helper_alloc_info
+ if (!info)
+ return ERR_PTR(-ENOMEM);
+
++ if (!drm_leak_fbdev_smem)
++ info->flags |= FBINFO_HIDE_SMEM_START;
++
+ ret = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (ret)
+ goto err_release;
+@@ -1860,9 +1863,6 @@ __drm_fb_helper_initial_config_and_unloc
+ info = fb_helper->info;
+ info->var.pixclock = 0;
+
+- if (!drm_leak_fbdev_smem)
+- info->flags |= FBINFO_HIDE_SMEM_START;
+-
+ /* Need to drop locks to avoid recursive deadlock in
+ * register_framebuffer. This is ok because the only thing left to do is
+ * register the fbdev emulation instance in kernel_fb_helper_list. */
+--- a/drivers/gpu/drm/drm_fbdev_dma.c
++++ b/drivers/gpu/drm/drm_fbdev_dma.c
+@@ -130,7 +130,10 @@ static int drm_fbdev_dma_helper_fb_probe
+ info->flags |= FBINFO_READS_FAST; /* signal caching */
+ info->screen_size = sizes->surface_height * fb->pitches[0];
+ info->screen_buffer = map.vaddr;
+- info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
++ if (!(info->flags & FBINFO_HIDE_SMEM_START)) {
++ if (!drm_WARN_ON(dev, is_vmalloc_addr(info->screen_buffer)))
++ info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
++ }
+ info->fix.smem_len = info->screen_size;
+
+ return 0;
--- /dev/null
+From 996c3412a06578e9d779a16b9e79ace18125ab50 Mon Sep 17 00:00:00 2001
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Date: Mon, 3 Jun 2024 21:54:45 +0200
+Subject: drm/i915/gt: Fix potential UAF by revoke of fence registers
+
+From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+
+commit 996c3412a06578e9d779a16b9e79ace18125ab50 upstream.
+
+CI has been sporadically reporting the following issue triggered by
+igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
+
+<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
+...
+<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
+<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
+<3> [414.070354] Unable to pin Y-tiled fence; err:-4
+<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active))
+...
+<4>[ 609.603992] ------------[ cut here ]------------
+<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
+<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
+<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
+<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]
+<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
+...
+<4>[ 609.604271] Call Trace:
+<4>[ 609.604273] <TASK>
+...
+<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]
+<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]
+<4>[ 609.604977] force_unbind+0x24/0xa0 [i915]
+<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]
+<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
+<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
+<4>[ 609.605440] process_scheduled_works+0x351/0x690
+...
+
+In the past, there were similar failures reported by CI from other IGT
+tests, observed on other platforms.
+
+Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
+before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
+idleness of vma->active via fence_update(). That commit introduced
+vma->fence->active in order for the fence_update() to be able to wait
+selectively on that one instead of vma->active since only idleness of
+fence registers was needed. But then, another commit 0d86ee35097a
+("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
+fence_update() in i915_vma_revoke_fence() with only fence_write(), and
+also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front.
+No justification was provided on why we might then expect idleness of
+vma->fence->active without first waiting on it.
+
+The issue can be potentially caused by a race among revocation of fence
+registers on one side and sequential execution of signal callbacks invoked
+on completion of a request that was using them on the other, still
+processed in parallel to revocation of those fence registers. Fix it by
+waiting for idleness of vma->fence->active in i915_vma_revoke_fence().
+
+Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal")
+Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021
+Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
+Cc: stable@vger.kernel.org # v5.8+
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240603195446.297690-2-janusz.krzysztofik@linux.intel.com
+(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
++++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+@@ -298,6 +298,7 @@ void i915_vma_revoke_fence(struct i915_v
+ return;
+
+ GEM_BUG_ON(fence->vma != vma);
++ i915_active_wait(&fence->active);
+ GEM_BUG_ON(!i915_active_is_idle(&fence->active));
+ GEM_BUG_ON(atomic_read(&fence->pin_count));
+
--- /dev/null
+From 6d411c8ccc0137a612e0044489030a194ff5c843 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Tue, 25 Jun 2024 16:10:29 +0800
+Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream.
+
+In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
+assigned to mode, which will lead to a possible NULL pointer dereference
+on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
+Add a check to avoid null pointer dereference.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+@@ -260,6 +260,8 @@ static int nv17_tv_get_hd_modes(struct d
+ if (modes[i].hdisplay == output_mode->hdisplay &&
+ modes[i].vdisplay == output_mode->vdisplay) {
+ mode = drm_mode_duplicate(encoder->dev, output_mode);
++ if (!mode)
++ continue;
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ } else {
+@@ -267,6 +269,8 @@ static int nv17_tv_get_hd_modes(struct d
+ modes[i].vdisplay, 60, false,
+ (output_mode->flags &
+ DRM_MODE_FLAG_INTERLACE), false);
++ if (!mode)
++ continue;
+ }
+
+ /* CVT modes are sometimes unsuitable... */
--- /dev/null
+From 66edf3fb331b6c55439b10f9862987b0916b3726 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Tue, 25 Jun 2024 16:18:28 +0800
+Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 66edf3fb331b6c55439b10f9862987b0916b3726 upstream.
+
+In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
+assigned to mode, which will lead to a possible NULL pointer dereference
+on failure of drm_mode_duplicate(). Add a check to avoid npd.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240625081828.2620794-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+@@ -209,6 +209,8 @@ static int nv17_tv_get_ld_modes(struct d
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(encoder->dev, tv_mode);
++ if (!mode)
++ continue;
+
+ mode->clock = tv_norm->tv_enc_mode.vrefresh *
+ mode->htotal / 1000 *
--- /dev/null
+From 896842284c6ccba25ec9d78b7b6e62cdd507c083 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 20 Jun 2024 15:24:11 +0200
+Subject: hexagon: fix fadvise64_64 calling conventions
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 896842284c6ccba25ec9d78b7b6e62cdd507c083 upstream.
+
+fadvise64_64() has two 64-bit arguments at the wrong alignment
+for hexagon, which turns them into a 7-argument syscall that is
+not supported by Linux.
+
+The downstream musl port for hexagon actually asks for a 6-argument
+version the same way we do it on arm, csky, powerpc, so make the
+kernel do it the same way to avoid having to change both.
+
+Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78
+Cc: stable@vger.kernel.org
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/hexagon/include/asm/syscalls.h | 6 ++++++
+ arch/hexagon/kernel/syscalltab.c | 7 +++++++
+ 2 files changed, 13 insertions(+)
+ create mode 100644 arch/hexagon/include/asm/syscalls.h
+
+--- /dev/null
++++ b/arch/hexagon/include/asm/syscalls.h
+@@ -0,0 +1,6 @@
++/* SPDX-License-Identifier: GPL-2.0 */
++
++#include <asm-generic/syscalls.h>
++
++asmlinkage long sys_hexagon_fadvise64_64(int fd, int advice,
++ u32 a2, u32 a3, u32 a4, u32 a5);
+--- a/arch/hexagon/kernel/syscalltab.c
++++ b/arch/hexagon/kernel/syscalltab.c
+@@ -14,6 +14,13 @@
+ #undef __SYSCALL
+ #define __SYSCALL(nr, call) [nr] = (call),
+
++SYSCALL_DEFINE6(hexagon_fadvise64_64, int, fd, int, advice,
++ SC_ARG64(offset), SC_ARG64(len))
++{
++ return ksys_fadvise64_64(fd, SC_VAL64(loff_t, offset), SC_VAL64(loff_t, len), advice);
++}
++#define sys_fadvise64_64 sys_hexagon_fadvise64_64
++
+ void *sys_call_table[__NR_syscalls] = {
+ #include <asm/unistd.h>
+ };
--- /dev/null
+From 2d64eaeeeda5659d52da1af79d237269ba3c2d2c Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Sun, 23 Jun 2024 11:41:13 +0800
+Subject: irqchip/loongson-eiointc: Use early_cpu_to_node() instead of cpu_to_node()
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 2d64eaeeeda5659d52da1af79d237269ba3c2d2c upstream.
+
+Multi-bridge machines required that all eiointc controllers in the system
+are initialized, otherwise the system does not boot.
+
+The initialization happens on the boot CPU during early boot and relies on
+cpu_to_node() for identifying the individual nodes.
+
+That works when the number of possible CPUs is large enough, but with a
+command line limit, e.g. "nr_cpus=$N" for kdump, but fails when the CPUs
+of the secondary nodes are not covered.
+
+During early ACPI enumeration all CPU to node mappings are recorded up to
+CONFIG_NR_CPUS. These are accessible via early_cpu_to_node() even in the
+case that "nr_cpus=N" truncates the number of possible CPUs and only
+provides the possible CPUs via cpu_to_node() translation.
+
+Change the node lookup in the driver to use early_cpu_to_node() so that
+even with a limitation on the number of possible CPUs all eointc instances
+are initialized.
+
+This can't obviously cure the case where CONFIG_NR_CPUS is too small.
+
+[ tglx: Massaged changelog ]
+
+Fixes: 64cc451e45e1 ("irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent")
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240623034113.1808727-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-loongson-eiointc.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-loongson-eiointc.c
++++ b/drivers/irqchip/irq-loongson-eiointc.c
+@@ -15,6 +15,7 @@
+ #include <linux/irqchip/chained_irq.h>
+ #include <linux/kernel.h>
+ #include <linux/syscore_ops.h>
++#include <asm/numa.h>
+
+ #define EIOINTC_REG_NODEMAP 0x14a0
+ #define EIOINTC_REG_IPMAP 0x14c0
+@@ -339,7 +340,7 @@ static int __init pch_msi_parse_madt(uni
+ int node;
+
+ if (cpu_has_flatmode)
+- node = cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE);
++ node = early_cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE);
+ else
+ node = eiointc_priv[nr_pics - 1]->node;
+
+@@ -431,7 +432,7 @@ int __init eiointc_acpi_init(struct irq_
+ goto out_free_handle;
+
+ if (cpu_has_flatmode)
+- node = cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE);
++ node = early_cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE);
+ else
+ node = acpi_eiointc->node;
+ acpi_set_vec_parent(node, priv->eiointc_domain, pch_group);
--- /dev/null
+From a9c3ee5d0fdb069b54902300df6ac822027f3b0a Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Sat, 22 Jun 2024 12:33:38 +0800
+Subject: irqchip/loongson-liointc: Set different ISRs for different cores
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit a9c3ee5d0fdb069b54902300df6ac822027f3b0a upstream.
+
+The liointc hardware provides separate Interrupt Status Registers (ISR) for
+each core. The current code uses always the ISR of core #0, which works
+during boot because by default all interrupts are routed to core #0.
+
+When the interrupt routing changes in the firmware configuration then this
+causes interrupts to be lost because they are not configured in the
+corresponding core.
+
+Use the core index to access the correct ISR instead of a hardcoded 0.
+
+[ tglx: Massaged changelog ]
+
+Fixes: 0858ed035a85 ("irqchip/loongson-liointc: Add ACPI init support")
+Co-developed-by: Tianli Xiong <xiongtianli@loongson.cn>
+Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240622043338.1566945-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-loongson-liointc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-loongson-liointc.c
++++ b/drivers/irqchip/irq-loongson-liointc.c
+@@ -28,7 +28,7 @@
+
+ #define LIOINTC_INTC_CHIP_START 0x20
+
+-#define LIOINTC_REG_INTC_STATUS (LIOINTC_INTC_CHIP_START + 0x20)
++#define LIOINTC_REG_INTC_STATUS(core) (LIOINTC_INTC_CHIP_START + 0x20 + (core) * 8)
+ #define LIOINTC_REG_INTC_EN_STATUS (LIOINTC_INTC_CHIP_START + 0x04)
+ #define LIOINTC_REG_INTC_ENABLE (LIOINTC_INTC_CHIP_START + 0x08)
+ #define LIOINTC_REG_INTC_DISABLE (LIOINTC_INTC_CHIP_START + 0x0c)
+@@ -217,7 +217,7 @@ static int liointc_init(phys_addr_t addr
+ goto out_free_priv;
+
+ for (i = 0; i < LIOINTC_NUM_CORES; i++)
+- priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
++ priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS(i);
+
+ for (i = 0; i < LIOINTC_NUM_PARENT; i++)
+ priv->handler[i].parent_int_map = parent_int_map[i];
--- /dev/null
+From 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e Mon Sep 17 00:00:00 2001
+From: Dragan Simic <dsimic@manjaro.org>
+Date: Mon, 10 Jun 2024 07:21:12 +0200
+Subject: kbuild: Install dtb files as 0644 in Makefile.dtbinst
+
+From: Dragan Simic <dsimic@manjaro.org>
+
+commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream.
+
+The compiled dtb files aren't executable, so install them with 0644 as their
+permission mode, instead of defaulting to 0755 for the permission mode and
+installing them with the executable bits set.
+
+Some Linux distributions, including Debian, [1][2][3] already include fixes
+in their kernel package build recipes to change the dtb file permissions to
+0644 in their kernel packages. These changes, when additionally propagated
+into the long-term kernel versions, will allow such distributions to remove
+their downstream fixes.
+
+[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642
+[2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749
+[3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193
+
+Cc: Diederik de Haas <didi.debian@cknow.org>
+Cc: <stable@vger.kernel.org>
+Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more")
+Signed-off-by: Dragan Simic <dsimic@manjaro.org>
+Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ scripts/Makefile.dtbinst | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/scripts/Makefile.dtbinst
++++ b/scripts/Makefile.dtbinst
+@@ -17,7 +17,7 @@ include $(srctree)/scripts/Kbuild.includ
+ dst := $(INSTALL_DTBS_PATH)
+
+ quiet_cmd_dtb_install = INSTALL $@
+- cmd_dtb_install = install -D $< $@
++ cmd_dtb_install = install -D -m 0644 $< $@
+
+ $(dst)/%: $(obj)/%
+ $(call cmd,dtb_install)
--- /dev/null
+From d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+Date: Fri, 17 Nov 2023 13:49:59 +0100
+Subject: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream.
+
+This patch enhances error handling in scenarios with RTS (Request to
+Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
+backtraces with a new error handling method. This provides clearer error
+messages and allows for the early termination of problematic sessions.
+Previously, sessions were only released at the end of j1939_xtp_rx_rts().
+
+Potentially this could be reproduced with something like:
+testj1939 -r vcan0:0x80 &
+while true; do
+ # send first RTS
+ cansend vcan0 18EC8090#1014000303002301;
+ # send second RTS
+ cansend vcan0 18EC8090#1014000303002301;
+ # send abort
+ cansend vcan0 18EC8090#ff00000000002301;
+done
+
+Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
+Reported-by: syzbot+daa36413a5cedf799ae4@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/transport.c | 19 +++++++++++++++++--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+--- a/net/can/j1939/transport.c
++++ b/net/can/j1939/transport.c
+@@ -1593,8 +1593,8 @@ j1939_session *j1939_xtp_rx_rts_session_
+ struct j1939_sk_buff_cb skcb = *j1939_skb_to_cb(skb);
+ struct j1939_session *session;
+ const u8 *dat;
++ int len, ret;
+ pgn_t pgn;
+- int len;
+
+ netdev_dbg(priv->ndev, "%s\n", __func__);
+
+@@ -1653,7 +1653,22 @@ j1939_session *j1939_xtp_rx_rts_session_
+ session->tskey = priv->rx_tskey++;
+ j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_RTS);
+
+- WARN_ON_ONCE(j1939_session_activate(session));
++ ret = j1939_session_activate(session);
++ if (ret) {
++ /* Entering this scope indicates an issue with the J1939 bus.
++ * Possible scenarios include:
++ * - A time lapse occurred, and a new session was initiated
++ * due to another packet being sent correctly. This could
++ * have been caused by too long interrupt, debugger, or being
++ * out-scheduled by another task.
++ * - The bus is receiving numerous erroneous packets, either
++ * from a malfunctioning device or during a test scenario.
++ */
++ netdev_alert(priv->ndev, "%s: 0x%p: concurrent session with same addr (%02x %02x) is already active.\n",
++ __func__, session, skcb.addr.sa, skcb.addr.da);
++ j1939_session_put(session);
++ return NULL;
++ }
+
+ return session;
+ }
--- /dev/null
+From b7cdf1dd5d2a2d8200efd98d1893684db48fe134 Mon Sep 17 00:00:00 2001
+From: Shigeru Yoshida <syoshida@redhat.com>
+Date: Fri, 17 May 2024 12:59:53 +0900
+Subject: net: can: j1939: Initialize unused data in j1939_send_one()
+
+From: Shigeru Yoshida <syoshida@redhat.com>
+
+commit b7cdf1dd5d2a2d8200efd98d1893684db48fe134 upstream.
+
+syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
+creates full frame including unused data, but it doesn't initialize
+it. This causes the kernel-infoleak issue. Fix this by initializing
+unused data.
+
+[1]
+BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
+BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ instrument_copy_to_user include/linux/instrumented.h:114 [inline]
+ copy_to_user_iter lib/iov_iter.c:24 [inline]
+ iterate_ubuf include/linux/iov_iter.h:29 [inline]
+ iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
+ iterate_and_advance include/linux/iov_iter.h:271 [inline]
+ _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
+ copy_to_iter include/linux/uio.h:196 [inline]
+ memcpy_to_msg include/linux/skbuff.h:4113 [inline]
+ raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
+ sock_recvmsg_nosec net/socket.c:1046 [inline]
+ sock_recvmsg+0x2c4/0x340 net/socket.c:1068
+ ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
+ ___sys_recvmsg+0x223/0x840 net/socket.c:2845
+ do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939
+ __sys_recvmmsg net/socket.c:3018 [inline]
+ __do_sys_recvmmsg net/socket.c:3041 [inline]
+ __se_sys_recvmmsg net/socket.c:3034 [inline]
+ __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034
+ x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Uninit was created at:
+ slab_post_alloc_hook mm/slub.c:3804 [inline]
+ slab_alloc_node mm/slub.c:3845 [inline]
+ kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
+ kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
+ __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
+ alloc_skb include/linux/skbuff.h:1313 [inline]
+ alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
+ sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
+ sock_alloc_send_skb include/net/sock.h:1842 [inline]
+ j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
+ j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
+ j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
+ sock_sendmsg_nosec net/socket.c:730 [inline]
+ __sock_sendmsg+0x30f/0x380 net/socket.c:745
+ ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
+ ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
+ __sys_sendmsg net/socket.c:2667 [inline]
+ __do_sys_sendmsg net/socket.c:2676 [inline]
+ __se_sys_sendmsg net/socket.c:2674 [inline]
+ __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
+ x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
+ do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+ do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+Bytes 12-15 of 16 are uninitialized
+Memory access of size 16 starts at ffff888120969690
+Data copied to user address 00000000200017c0
+
+CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
+
+Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
+Reported-and-tested-by: syzbot+5681e40d297b30f5b513@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=5681e40d297b30f5b513
+Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
+Link: https://lore.kernel.org/all/20240517035953.2617090-1-syoshida@redhat.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/main.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/net/can/j1939/main.c
++++ b/net/can/j1939/main.c
+@@ -30,10 +30,6 @@ MODULE_ALIAS("can-proto-" __stringify(CA
+ /* CAN_HDR: #bytes before can_frame data part */
+ #define J1939_CAN_HDR (offsetof(struct can_frame, data))
+
+-/* CAN_FTR: #bytes beyond data part */
+-#define J1939_CAN_FTR (sizeof(struct can_frame) - J1939_CAN_HDR - \
+- sizeof(((struct can_frame *)0)->data))
+-
+ /* lowest layer */
+ static void j1939_can_recv(struct sk_buff *iskb, void *data)
+ {
+@@ -342,7 +338,7 @@ int j1939_send_one(struct j1939_priv *pr
+ memset(cf, 0, J1939_CAN_HDR);
+
+ /* make it a full can frame again */
+- skb_put(skb, J1939_CAN_FTR + (8 - dlc));
++ skb_put_zero(skb, 8 - dlc);
+
+ canid = CAN_EFF_FLAG |
+ (skcb->priority << 26) |
--- /dev/null
+From 9ad1da14ab3bf23087ae45fe399d84a109ddb81a Mon Sep 17 00:00:00 2001
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+Date: Tue, 28 May 2024 09:06:48 +0200
+Subject: net: can: j1939: recover socket queue on CAN bus error during BAM transmission
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Oleksij Rempel <o.rempel@pengutronix.de>
+
+commit 9ad1da14ab3bf23087ae45fe399d84a109ddb81a upstream.
+
+Addresses an issue where a CAN bus error during a BAM transmission
+could stall the socket queue, preventing further transmissions even
+after the bus error is resolved. The fix activates the next queued
+session after the error recovery, allowing communication to continue.
+
+Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol")
+Cc: stable@vger.kernel.org
+Reported-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
+Tested-by: Alexander Hölzl <alexander.hoelzl@gmx.net>
+Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
+Link: https://lore.kernel.org/all/20240528070648.1947203-1-o.rempel@pengutronix.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/can/j1939/transport.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/can/j1939/transport.c
++++ b/net/can/j1939/transport.c
+@@ -1681,6 +1681,8 @@ static int j1939_xtp_rx_rts_session_acti
+
+ j1939_session_timers_cancel(session);
+ j1939_session_cancel(session, J1939_XTP_ABORT_BUSY);
++ if (session->transmission)
++ j1939_session_deactivate_activate_next(session);
+
+ return -EBUSY;
+ }
--- /dev/null
+From 440e2051c577896275c0e0513ec26964e04c7810 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Wed, 29 May 2024 14:42:40 -0700
+Subject: nvmet-fc: Remove __counted_by from nvmet_fc_tgt_queue.fod[]
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 440e2051c577896275c0e0513ec26964e04c7810 upstream.
+
+Work for __counted_by on generic pointers in structures (not just
+flexible array members) has started landing in Clang 19 (current tip of
+tree). During the development of this feature, a restriction was added
+to __counted_by to prevent the flexible array member's element type from
+including a flexible array member itself such as:
+
+ struct foo {
+ int count;
+ char buf[];
+ };
+
+ struct bar {
+ int count;
+ struct foo data[] __counted_by(count);
+ };
+
+because the size of data cannot be calculated with the standard array
+size formula:
+
+ sizeof(struct foo) * count
+
+This restriction was downgraded to a warning but due to CONFIG_WERROR,
+it can still break the build. The application of __counted_by on the fod
+member of 'struct nvmet_fc_tgt_queue' triggers this restriction,
+resulting in:
+
+ drivers/nvme/target/fc.c:151:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct nvmet_fc_fcp_iod' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size]
+ 151 | struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize);
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ 1 error generated.
+
+Remove this use of __counted_by to fix the warning/error. However,
+rather than remove it altogether, leave it commented, as it may be
+possible to support this in future compiler releases.
+
+Cc: stable@vger.kernel.org
+Closes: https://github.com/ClangBuiltLinux/linux/issues/2027
+Fixes: ccd3129aca28 ("nvmet-fc: Annotate struct nvmet_fc_tgt_queue with __counted_by")
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/fc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/nvme/target/fc.c
++++ b/drivers/nvme/target/fc.c
+@@ -148,7 +148,7 @@ struct nvmet_fc_tgt_queue {
+ struct workqueue_struct *work_q;
+ struct kref ref;
+ /* array of fcp_iods */
+- struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize);
++ struct nvmet_fc_fcp_iod fod[] /* __counted_by(sqsize) */;
+ } __aligned(sizeof(unsigned long long));
+
+ struct nvmet_fc_hostport {
--- /dev/null
+From 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 Mon Sep 17 00:00:00 2001
+From: Mostafa Saleh <smostafa@google.com>
+Date: Mon, 24 Jun 2024 20:37:28 +0000
+Subject: PCI/MSI: Fix UAF in msi_capability_init
+
+From: Mostafa Saleh <smostafa@google.com>
+
+commit 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 upstream.
+
+KFENCE reports the following UAF:
+
+ BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488
+
+ Use-after-free read at 0x0000000024629571 (in kfence-#12):
+ __pci_enable_msi_range+0x2c0/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+ kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128
+
+ allocated by task 81 on cpu 7 at 10.808142s:
+ __kmem_cache_alloc_node+0x1f0/0x2bc
+ kmalloc_trace+0x44/0x138
+ msi_alloc_desc+0x3c/0x9c
+ msi_domain_insert_msi_desc+0x30/0x78
+ msi_setup_msi_desc+0x13c/0x184
+ __pci_enable_msi_range+0x258/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+ freed by task 81 on cpu 7 at 10.811436s:
+ msi_domain_free_descs+0xd4/0x10c
+ msi_domain_free_locked.part.0+0xc0/0x1d8
+ msi_domain_alloc_irqs_all_locked+0xb4/0xbc
+ pci_msi_setup_msi_irqs+0x30/0x4c
+ __pci_enable_msi_range+0x2a8/0x488
+ pci_alloc_irq_vectors_affinity+0xec/0x14c
+ pci_alloc_irq_vectors+0x18/0x28
+
+Descriptor allocation done in:
+__pci_enable_msi_range
+ msi_capability_init
+ msi_setup_msi_desc
+ msi_insert_msi_desc
+ msi_domain_insert_msi_desc
+ msi_alloc_desc
+ ...
+
+Freed in case of failure in __msi_domain_alloc_locked()
+__pci_enable_msi_range
+ msi_capability_init
+ pci_msi_setup_msi_irqs
+ msi_domain_alloc_irqs_all_locked
+ msi_domain_alloc_locked
+ __msi_domain_alloc_locked => fails
+ msi_domain_free_locked
+ ...
+
+That failure propagates back to pci_msi_setup_msi_irqs() in
+msi_capability_init() which accesses the descriptor for unmasking in the
+error exit path.
+
+Cure it by copying the descriptor and using the copy for the error exit path
+unmask operation.
+
+[ tglx: Massaged change log ]
+
+Fixes: bf6e054e0e3f ("genirq/msi: Provide msi_device_populate/destroy_sysfs()")
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Mostafa Saleh <smostafa@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Bjorn Heelgas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240624203729.1094506-1-smostafa@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/msi/msi.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/pci/msi/msi.c
++++ b/drivers/pci/msi/msi.c
+@@ -349,7 +349,7 @@ static int msi_capability_init(struct pc
+ struct irq_affinity *affd)
+ {
+ struct irq_affinity_desc *masks = NULL;
+- struct msi_desc *entry;
++ struct msi_desc *entry, desc;
+ int ret;
+
+ /* Reject multi-MSI early on irq domain enabled architectures */
+@@ -374,6 +374,12 @@ static int msi_capability_init(struct pc
+ /* All MSIs are unmasked by default; mask them all */
+ entry = msi_first_desc(&dev->dev, MSI_DESC_ALL);
+ pci_msi_mask(entry, msi_multi_mask(entry));
++ /*
++ * Copy the MSI descriptor for the error path because
++ * pci_msi_setup_msi_irqs() will free it for the hierarchical
++ * interrupt domain case.
++ */
++ memcpy(&desc, entry, sizeof(desc));
+
+ /* Configure MSI capability structure */
+ ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI);
+@@ -393,7 +399,7 @@ static int msi_capability_init(struct pc
+ goto unlock;
+
+ err:
+- pci_msi_unmask(entry, msi_multi_mask(entry));
++ pci_msi_unmask(&desc, msi_multi_mask(&desc));
+ pci_free_msi_irqs(dev);
+ fail:
+ dev->msi_enabled = 0;
serial-imx-set-receiver-level-before-starting-uart.patch
serial-core-introduce-uart_port_tx_limited_flags.patch
serial-bcm63xx-uart-fix-tx-after-conversion-to-uart_port_tx_limited.patch
+alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch
+tty-mxser-remove-__counted_by-from-mxser_board.ports.patch
+tty-mcf-mcf54418-has-10-uarts.patch
+net-can-j1939-initialize-unused-data-in-j1939_send_one.patch
+net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch
+net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch
+pci-msi-fix-uaf-in-msi_capability_init.patch
+nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch
+cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch
+irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch
+cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch
+cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch
+irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch
+kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch
+sh-rework-sync_file_range-abi.patch
+btrfs-zoned-fix-initial-free-space-detection.patch
+csky-hexagon-fix-broken-sys_sync_file_range.patch
+hexagon-fix-fadvise64_64-calling-conventions.patch
+drm-drm_file-fix-pid-refcounting-race.patch
+drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch
+drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch
+drm-amdgpu-avoid-using-null-object-of-framebuffer.patch
+drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch
+drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch
+drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch
+drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch
--- /dev/null
+From 30766f1105d6d2459c3b9fe34a3e52b637a72950 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Tue, 11 Jun 2024 22:12:43 +0200
+Subject: sh: rework sync_file_range ABI
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 30766f1105d6d2459c3b9fe34a3e52b637a72950 upstream.
+
+The unusual function calling conventions on SuperH ended up causing
+sync_file_range to have the wrong argument order, with the 'flags'
+argument getting sorted before 'nbytes' by the compiler.
+
+In userspace, I found that musl, glibc, uclibc and strace all expect the
+normal calling conventions with 'nbytes' last, so changing the kernel
+to match them should make all of those work.
+
+In order to be able to also fix libc implementations to work with existing
+kernels, they need to be able to tell which ABI is used. An easy way
+to do this is to add yet another system call using the sync_file_range2
+ABI that works the same on all architectures.
+
+Old user binaries can now work on new kernels, and new binaries can
+try the new sync_file_range2() to work with new kernels or fall back
+to the old sync_file_range() version if that doesn't exist.
+
+Cc: stable@vger.kernel.org
+Fixes: 75c92acdd5b1 ("sh: Wire up new syscalls.")
+Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/sh/kernel/sys_sh32.c | 11 +++++++++++
+ arch/sh/kernel/syscalls/syscall.tbl | 3 ++-
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+--- a/arch/sh/kernel/sys_sh32.c
++++ b/arch/sh/kernel/sys_sh32.c
+@@ -59,3 +59,14 @@ asmlinkage int sys_fadvise64_64_wrapper(
+ (u64)len0 << 32 | len1, advice);
+ #endif
+ }
++
++/*
++ * swap the arguments the way that libc wants them instead of
++ * moving flags ahead of the 64-bit nbytes argument
++ */
++SYSCALL_DEFINE6(sh_sync_file_range6, int, fd, SC_ARG64(offset),
++ SC_ARG64(nbytes), unsigned int, flags)
++{
++ return ksys_sync_file_range(fd, SC_VAL64(loff_t, offset),
++ SC_VAL64(loff_t, nbytes), flags);
++}
+--- a/arch/sh/kernel/syscalls/syscall.tbl
++++ b/arch/sh/kernel/syscalls/syscall.tbl
+@@ -321,7 +321,7 @@
+ 311 common set_robust_list sys_set_robust_list
+ 312 common get_robust_list sys_get_robust_list
+ 313 common splice sys_splice
+-314 common sync_file_range sys_sync_file_range
++314 common sync_file_range sys_sh_sync_file_range6
+ 315 common tee sys_tee
+ 316 common vmsplice sys_vmsplice
+ 317 common move_pages sys_move_pages
+@@ -395,6 +395,7 @@
+ 385 common pkey_alloc sys_pkey_alloc
+ 386 common pkey_free sys_pkey_free
+ 387 common rseq sys_rseq
++388 common sync_file_range2 sys_sync_file_range2
+ # room for arch specific syscalls
+ 393 common semget sys_semget
+ 394 common semctl sys_semctl
--- /dev/null
+From 7c92a8bd53f24d50c8cf4aba53bb75505b382fed Mon Sep 17 00:00:00 2001
+From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+Date: Thu, 20 Jun 2024 18:29:59 +0200
+Subject: tty: mcf: MCF54418 has 10 UARTS
+
+From: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+
+commit 7c92a8bd53f24d50c8cf4aba53bb75505b382fed upstream.
+
+Most of the colfires have up to 5 UARTs but MCF54418 has up-to 10 !
+Change the maximum value authorized.
+
+Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
+Cc: stable <stable@kernel.org>
+Fixes: 2545cf6e94b4 ("m68knommu: allow 4 coldfire serial ports")
+Link: https://lore.kernel.org/r/20240620-upstream-uart-v1-1-a9d0d95fb19e@yoseli.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/mcf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/mcf.c
++++ b/drivers/tty/serial/mcf.c
+@@ -462,7 +462,7 @@ static const struct uart_ops mcf_uart_op
+ .verify_port = mcf_verify_port,
+ };
+
+-static struct mcf_uart mcf_ports[4];
++static struct mcf_uart mcf_ports[10];
+
+ #define MCF_MAXPORTS ARRAY_SIZE(mcf_ports)
+
--- /dev/null
+From 1c07c9be87dd3dd0634033bf08728b32465f08fb Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Wed, 29 May 2024 14:29:42 -0700
+Subject: tty: mxser: Remove __counted_by from mxser_board.ports[]
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 1c07c9be87dd3dd0634033bf08728b32465f08fb upstream.
+
+Work for __counted_by on generic pointers in structures (not just
+flexible array members) has started landing in Clang 19 (current tip of
+tree). During the development of this feature, a restriction was added
+to __counted_by to prevent the flexible array member's element type from
+including a flexible array member itself such as:
+
+ struct foo {
+ int count;
+ char buf[];
+ };
+
+ struct bar {
+ int count;
+ struct foo data[] __counted_by(count);
+ };
+
+because the size of data cannot be calculated with the standard array
+size formula:
+
+ sizeof(struct foo) * count
+
+This restriction was downgraded to a warning but due to CONFIG_WERROR,
+it can still break the build. The application of __counted_by on the
+ports member of 'struct mxser_board' triggers this restriction,
+resulting in:
+
+ drivers/tty/mxser.c:291:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct mxser_port' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size]
+ 291 | struct mxser_port ports[] __counted_by(nports);
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~
+ 1 error generated.
+
+Remove this use of __counted_by to fix the warning/error. However,
+rather than remove it altogether, leave it commented, as it may be
+possible to support this in future compiler releases.
+
+Cc: <stable@vger.kernel.org>
+Closes: https://github.com/ClangBuiltLinux/linux/issues/2026
+Fixes: f34907ecca71 ("mxser: Annotate struct mxser_board with __counted_by")
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20240529-drop-counted-by-ports-mxser-board-v1-1-0ab217f4da6d@kernel.org
+Signed-off-by: Kees Cook <kees@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/mxser.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/mxser.c
++++ b/drivers/tty/mxser.c
+@@ -288,7 +288,7 @@ struct mxser_board {
+ enum mxser_must_hwid must_hwid;
+ speed_t max_baud;
+
+- struct mxser_port ports[] __counted_by(nports);
++ struct mxser_port ports[] /* __counted_by(nports) */;
+ };
+
+ static DECLARE_BITMAP(mxser_boards, MXSER_BOARDS);
projects / thirdparty / kernel / stable-queue.git / commitdiff
