From: Greg Kroah-Hartman Date: Sun, 10 Sep 2023 18:31:25 +0000 (+0100) Subject: 6.5-stable patches X-Git-Tag: v6.1.53~27 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8bf1eb1e3ed403fddd919160fa058b07abf62bbe;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: perf-x86-uncore-correct-the-number-of-chas-on-emr.patch x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch x86-smp-don-t-send-init-to-non-present-and-non-booted-cpus.patch --- diff --git a/queue-6.5/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch b/queue-6.5/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch new file mode 100644 index 00000000000..fcd871bee86 --- /dev/null +++ b/queue-6.5/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch @@ -0,0 +1,61 @@ +From 6f7f984fa85b305799076a1bcec941b9377587de Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Tue, 5 Sep 2023 06:42:48 -0700 +Subject: perf/x86/uncore: Correct the number of CHAs on EMR + +From: Kan Liang + +commit 6f7f984fa85b305799076a1bcec941b9377587de upstream. + +Starting from SPR, the basic uncore PMON information is retrieved from +the discovery table (resides in an MMIO space populated by BIOS). It is +called the discovery method. The existing value of the type->num_boxes +is from the discovery table. + +On some SPR variants, there is a firmware bug that makes the value from the +discovery table incorrect. We use the value from the +SPR_MSR_UNC_CBO_CONFIG MSR to replace the one from the discovery table: + + 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR") + +Unfortunately, the SPR_MSR_UNC_CBO_CONFIG isn't available for the EMR +XCC (Always returns 0), but the above firmware bug doesn't impact the +EMR XCC. + +Don't let the value from the MSR replace the existing value from the +discovery table. + +Fixes: 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR") +Reported-by: Stephane Eranian +Reported-by: Yunying Sun +Signed-off-by: Kan Liang +Signed-off-by: Ingo Molnar +Tested-by: Yunying Sun +Link: https://lore.kernel.org/r/20230905134248.496114-1-kan.liang@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/uncore_snbep.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/uncore_snbep.c ++++ b/arch/x86/events/intel/uncore_snbep.c +@@ -6474,8 +6474,18 @@ void spr_uncore_cpu_init(void) + + type = uncore_find_type_by_id(uncore_msr_uncores, UNCORE_SPR_CHA); + if (type) { ++ /* ++ * The value from the discovery table (stored in the type->num_boxes ++ * of UNCORE_SPR_CHA) is incorrect on some SPR variants because of a ++ * firmware bug. Using the value from SPR_MSR_UNC_CBO_CONFIG to replace it. ++ */ + rdmsrl(SPR_MSR_UNC_CBO_CONFIG, num_cbo); +- type->num_boxes = num_cbo; ++ /* ++ * The MSR doesn't work on the EMR XCC, but the firmware bug doesn't impact ++ * the EMR XCC. Don't let the value from the MSR replace the existing value. ++ */ ++ if (num_cbo) ++ type->num_boxes = num_cbo; + } + spr_uncore_iio_free_running.num_boxes = uncore_type_max_boxes(uncore_msr_uncores, UNCORE_SPR_IIO); + } diff --git a/queue-6.5/series b/queue-6.5/series index d0e6798b183..c12cfff6de5 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -721,6 +721,10 @@ crypto-stm32-fix-mdmat-condition.patch cpufreq-brcmstb-avs-cpufreq-fix-warray-bounds-bug.patch of-property-fw_devlink-add-a-devlink-for-panel-followers.patch usb-core-fix-oversight-in-superspeed-initialization.patch +x86-smp-don-t-send-init-to-non-present-and-non-booted-cpus.patch +x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch +x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch +perf-x86-uncore-correct-the-number-of-chas-on-emr.patch bluetooth-msft-extended-monitor-tracking-by-address-.patch bluetooth-hci-introduce-hci_quirk_broken_le_coded.patch serial-sc16is7xx-remove-obsolete-out_thread-label.patch diff --git a/queue-6.5/x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch b/queue-6.5/x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch new file mode 100644 index 00000000000..6ce73ee29e6 --- /dev/null +++ b/queue-6.5/x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch @@ -0,0 +1,53 @@ +From 65e710899fd19f435f40268f3a92dfaa11f14470 Mon Sep 17 00:00:00 2001 +From: Song Liu +Date: Wed, 6 Sep 2023 10:52:15 -0700 +Subject: x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld + +From: Song Liu + +commit 65e710899fd19f435f40268f3a92dfaa11f14470 upstream. + +With ":text =0xcccc", ld.lld fills unused text area with 0xcccc0000. +Example objdump -D output: + + ffffffff82b04203: 00 00 add %al,(%rax) + ffffffff82b04205: cc int3 + ffffffff82b04206: cc int3 + ffffffff82b04207: 00 00 add %al,(%rax) + ffffffff82b04209: cc int3 + ffffffff82b0420a: cc int3 + +Replace it with ":text =0xcccccccc", so we get the following instead: + + ffffffff82b04203: cc int3 + ffffffff82b04204: cc int3 + ffffffff82b04205: cc int3 + ffffffff82b04206: cc int3 + ffffffff82b04207: cc int3 + ffffffff82b04208: cc int3 + +gcc/ld doesn't seem to have the same issue. The generated code stays the +same for gcc/ld. + +Signed-off-by: Song Liu +Signed-off-by: Ingo Molnar +Reviewed-by: Kees Cook +Acked-by: Peter Zijlstra (Intel) +Fixes: 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill bytes") +Link: https://lore.kernel.org/r/20230906175215.2236033-1-song@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/vmlinux.lds.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/vmlinux.lds.S ++++ b/arch/x86/kernel/vmlinux.lds.S +@@ -156,7 +156,7 @@ SECTIONS + ALIGN_ENTRY_TEXT_END + *(.gnu.warning) + +- } :text =0xcccc ++ } :text = 0xcccccccc + + /* End of text section, which should occupy whole number of pages */ + _etext = .; diff --git a/queue-6.5/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch b/queue-6.5/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch new file mode 100644 index 00000000000..0ceaa6fb722 --- /dev/null +++ b/queue-6.5/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch @@ -0,0 +1,70 @@ +From 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 Mon Sep 17 00:00:00 2001 +From: Jack Wang +Date: Wed, 6 Sep 2023 15:17:12 +0200 +Subject: x86/sgx: Break up long non-preemptible delays in sgx_vepc_release() + +From: Jack Wang + +commit 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 upstream. + +On large enclaves we hit the softlockup warning with following call trace: + + xa_erase() + sgx_vepc_release() + __fput() + task_work_run() + do_exit() + +The latency issue is similar to the one fixed in: + + 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") + +The test system has 64GB of enclave memory, and all is assigned to a single VM. +Release of 'vepc' takes a longer time and causes long latencies, which triggers +the softlockup warning. + +Add cond_resched() to give other tasks a chance to run and reduce +latencies, which also avoids the softlockup detector. + +[ mingo: Rewrote the changelog. ] + +Fixes: 540745ddbc70 ("x86/sgx: Introduce virtual EPC for use by KVM guests") +Reported-by: Yu Zhang +Signed-off-by: Jack Wang +Signed-off-by: Ingo Molnar +Tested-by: Yu Zhang +Reviewed-by: Jarkko Sakkinen +Reviewed-by: Kai Huang +Acked-by: Haitao Huang +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/sgx/virt.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kernel/cpu/sgx/virt.c ++++ b/arch/x86/kernel/cpu/sgx/virt.c +@@ -204,6 +204,7 @@ static int sgx_vepc_release(struct inode + continue; + + xa_erase(&vepc->page_array, index); ++ cond_resched(); + } + + /* +@@ -222,6 +223,7 @@ static int sgx_vepc_release(struct inode + list_add_tail(&epc_page->list, &secs_pages); + + xa_erase(&vepc->page_array, index); ++ cond_resched(); + } + + /* +@@ -243,6 +245,7 @@ static int sgx_vepc_release(struct inode + + if (sgx_vepc_free_page(epc_page)) + list_add_tail(&epc_page->list, &secs_pages); ++ cond_resched(); + } + + if (!list_empty(&secs_pages)) diff --git a/queue-6.5/x86-smp-don-t-send-init-to-non-present-and-non-booted-cpus.patch b/queue-6.5/x86-smp-don-t-send-init-to-non-present-and-non-booted-cpus.patch new file mode 100644 index 00000000000..7a82ede25be --- /dev/null +++ b/queue-6.5/x86-smp-don-t-send-init-to-non-present-and-non-booted-cpus.patch @@ -0,0 +1,41 @@ +From 3f874c9b2aae8e30463efc1872bea4baa9ed25dc Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Wed, 9 Aug 2023 20:52:20 +0200 +Subject: x86/smp: Don't send INIT to non-present and non-booted CPUs + +From: Thomas Gleixner + +commit 3f874c9b2aae8e30463efc1872bea4baa9ed25dc upstream. + +Vasant reported that kexec() can hang or reset the machine when it tries to +park CPUs via INIT. This happens when the kernel is using extended APIC, +but the present mask has APIC IDs >= 0x100 enumerated. + +As extended APIC can only handle 8 bit of APIC ID sending INIT to APIC ID +0x100 sends INIT to APIC ID 0x0. That's the boot CPU which is special on +x86 and INIT causes the system to hang or resets the machine. + +Prevent this by sending INIT only to those CPUs which have been booted +once. + +Fixes: 45e34c8af58f ("x86/smp: Put CPUs into INIT on shutdown if possible") +Reported-by: Dheeraj Kumar Srivastava +Signed-off-by: Thomas Gleixner +Tested-by: Vasant Hegde +Link: https://lore.kernel.org/r/87cyzwjbff.ffs@tglx +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/smpboot.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/smpboot.c ++++ b/arch/x86/kernel/smpboot.c +@@ -1356,7 +1356,7 @@ bool smp_park_other_cpus_in_init(void) + if (this_cpu) + return false; + +- for_each_present_cpu(cpu) { ++ for_each_cpu_and(cpu, &cpus_booted_once_mask, cpu_present_mask) { + if (cpu == this_cpu) + continue; + apicid = apic->cpu_present_to_apicid(cpu);