From: Greg Kroah-Hartman Date: Tue, 22 Apr 2025 07:24:23 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v6.1.135~101 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9800e7611de5c1770440ab3c514531ea1bfb872f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: cpufreq-reference-count-policy-in-cpufreq_update_limits.patch kbuild-add-fno-builtin-wcslen.patch --- diff --git a/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch b/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch new file mode 100644 index 0000000000..60a88705f9 --- /dev/null +++ b/queue-6.1/cpufreq-reference-count-policy-in-cpufreq_update_limits.patch @@ -0,0 +1,56 @@ +From 9e4e249018d208678888bdf22f6b652728106528 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Fri, 28 Mar 2025 21:39:08 +0100 +Subject: cpufreq: Reference count policy in cpufreq_update_limits() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Rafael J. Wysocki + +commit 9e4e249018d208678888bdf22f6b652728106528 upstream. + +Since acpi_processor_notify() can be called before registering a cpufreq +driver or even in cases when a cpufreq driver is not registered at all, +cpufreq_update_limits() needs to check if a cpufreq driver is present +and prevent it from being unregistered. + +For this purpose, make it call cpufreq_cpu_get() to obtain a cpufreq +policy pointer for the given CPU and reference count the corresponding +policy object, if present. + +Fixes: 5a25e3f7cc53 ("cpufreq: intel_pstate: Driver-specific handling of _PPC updates") +Closes: https://lore.kernel.org/linux-acpi/Z-ShAR59cTow0KcR@mail-itl +Reported-by: Marek Marczykowski-Górecki +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Acked-by: Viresh Kumar +Link: https://patch.msgid.link/1928789.tdWV9SEqCh@rjwysocki.net +[do not use __free(cpufreq_cpu_put) in a backport] +Signed-off-by: Marek Marczykowski-Górecki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/cpufreq.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/cpufreq/cpufreq.c ++++ b/drivers/cpufreq/cpufreq.c +@@ -2691,10 +2691,18 @@ EXPORT_SYMBOL(cpufreq_update_policy); + */ + void cpufreq_update_limits(unsigned int cpu) + { ++ struct cpufreq_policy *policy; ++ ++ policy = cpufreq_cpu_get(cpu); ++ if (!policy) ++ return; ++ + if (cpufreq_driver->update_limits) + cpufreq_driver->update_limits(cpu); + else + cpufreq_update_policy(cpu); ++ ++ cpufreq_cpu_put(policy); + } + EXPORT_SYMBOL_GPL(cpufreq_update_limits); + diff --git a/queue-6.1/kbuild-add-fno-builtin-wcslen.patch b/queue-6.1/kbuild-add-fno-builtin-wcslen.patch new file mode 100644 index 0000000000..e3c3f015f2 --- /dev/null +++ b/queue-6.1/kbuild-add-fno-builtin-wcslen.patch @@ -0,0 +1,59 @@ +From a87930300e5abe2d100b17d7941eb2a4357b88b6 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Mon, 7 Apr 2025 16:22:12 -0700 +Subject: kbuild: Add '-fno-builtin-wcslen' + +From: Nathan Chancellor + +commit 84ffc79bfbf70c779e60218563f2f3ad45288671 upstream. + +A recent optimization change in LLVM [1] aims to transform certain loop +idioms into calls to strlen() or wcslen(). This change transforms the +first while loop in UniStrcat() into a call to wcslen(), breaking the +build when UniStrcat() gets inlined into alloc_path_with_tree_prefix(): + + ld.lld: error: undefined symbol: wcslen + >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) + >>> vmlinux.o:(alloc_path_with_tree_prefix) + >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) + >>> vmlinux.o:(alloc_path_with_tree_prefix) + +Disable this optimization with '-fno-builtin-wcslen', which prevents the +compiler from assuming that wcslen() is available in the kernel's C +library. + +[ More to the point - it's not that we couldn't implement wcslen(), it's + that this isn't an optimization at all in the context of the kernel. + + Replacing a simple inlined loop with a function call to the same loop + is just stupid and pointless if you don't have long strings and fancy + libraries with vectorization support etc. + + For the regular 'strlen()' cases, we want the compiler to do this in + order to handle the trivial case of constant strings. And we do have + optimized versions of 'strlen()' on some architectures. But for + wcslen? Just no. - Linus ] + +Cc: stable@vger.kernel.org +Link: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1] +Signed-off-by: Nathan Chancellor +Signed-off-by: Linus Torvalds +[nathan: Resolve small conflict in older trees] +Signed-off-by: Nathan Chancellor +Signed-off-by: Greg Kroah-Hartman +--- + Makefile | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/Makefile ++++ b/Makefile +@@ -1075,6 +1075,9 @@ KBUILD_CFLAGS += $(call cc-option,-Wer + # Require designated initializers for all marked structures + KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init) + ++# Ensure compilers do not transform certain loops into calls to wcslen() ++KBUILD_CFLAGS += -fno-builtin-wcslen ++ + # change __FILE__ to the relative path from the srctree + KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) + diff --git a/queue-6.1/series b/queue-6.1/series index 72606b203f..41630ca3b1 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -256,3 +256,5 @@ kvm-arm64-refactor-exit-handlers.patch kvm-arm64-mark-some-header-functions-as-inline.patch kvm-arm64-calculate-cptr_el2-traps-on-activating-traps.patch kvm-arm64-eagerly-switch-zcr_el-1-2.patch +cpufreq-reference-count-policy-in-cpufreq_update_limits.patch +kbuild-add-fno-builtin-wcslen.patch