From: Greg Kroah-Hartman Date: Sun, 10 Sep 2023 18:31:15 +0000 (+0100) Subject: 6.4-stable patches X-Git-Tag: v6.1.53~28 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1503ce36aabc6b3bbcaa362239928b1ec7ab8c77;p=thirdparty%2Fkernel%2Fstable-queue.git 6.4-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 --- diff --git a/queue-6.4/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch b/queue-6.4/perf-x86-uncore-correct-the-number-of-chas-on-emr.patch new file mode 100644 index 00000000000..fcd871bee86 --- /dev/null +++ b/queue-6.4/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.4/series b/queue-6.4/series index 1000cc79623..0f9da8f95b4 100644 --- a/queue-6.4/series +++ b/queue-6.4/series @@ -718,6 +718,9 @@ usb-core-unite-old-scheme-and-new-scheme-descriptor-reads.patch usb-core-change-usb_get_device_descriptor-api.patch usb-core-fix-race-by-not-overwriting-udev-descriptor-in-hub_port_init.patch usb-core-fix-oversight-in-superspeed-initialization.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 loongarch-ensure-fp-simd-registers-in-the-core-dump-.patch bluetooth-msft-extended-monitor-tracking-by-address-.patch bluetooth-hci-introduce-hci_quirk_broken_le_coded.patch diff --git a/queue-6.4/x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch b/queue-6.4/x86-build-fix-linker-fill-bytes-quirk-incompatibility-for-ld.lld.patch new file mode 100644 index 00000000000..6ce73ee29e6 --- /dev/null +++ b/queue-6.4/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.4/x86-sgx-break-up-long-non-preemptible-delays-in-sgx_vepc_release.patch b/queue-6.4/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.4/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))