From: Greg Kroah-Hartman Date: Thu, 7 Sep 2023 10:20:58 +0000 (+0100) Subject: 6.4-stable patches X-Git-Tag: v6.1.53~149 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=cd94527244db99784a80076d8ffb454103a82e36;p=thirdparty%2Fkernel%2Fstable-queue.git 6.4-stable patches added patches: cpufreq-intel_pstate-set-stale-cpu-frequency-to-minimum.patch sbitmap-fix-batching-wakeup.patch tpm-enable-hwrng-only-for-pluton-on-amd-cpus.patch --- diff --git a/queue-6.4/cpufreq-intel_pstate-set-stale-cpu-frequency-to-minimum.patch b/queue-6.4/cpufreq-intel_pstate-set-stale-cpu-frequency-to-minimum.patch new file mode 100644 index 00000000000..6b787f9273d --- /dev/null +++ b/queue-6.4/cpufreq-intel_pstate-set-stale-cpu-frequency-to-minimum.patch @@ -0,0 +1,47 @@ +From d51847acb018d83186e4af67bc93f9a00a8644f7 Mon Sep 17 00:00:00 2001 +From: Doug Smythies +Date: Sun, 20 Aug 2023 13:46:49 -0700 +Subject: cpufreq: intel_pstate: set stale CPU frequency to minimum + +From: Doug Smythies + +commit d51847acb018d83186e4af67bc93f9a00a8644f7 upstream. + +The intel_pstate CPU frequency scaling driver does not +use policy->cur and it is 0. +When the CPU frequency is outdated arch_freq_get_on_cpu() +will default to the nominal clock frequency when its call to +cpufreq_quick_getpolicy_cur returns the never updated 0. +Thus, the listed frequency might be outside of currently +set limits. Some users are complaining about the high +reported frequency, albeit stale, when their system is +idle and/or it is above the reduced maximum they have set. + +This patch will maintain policy_cur for the intel_pstate +driver at the current minimum CPU frequency. + +Reported-by: Yang Jie +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217597 +Signed-off-by: Doug Smythies +[ rjw: White space damage fixes and comment adjustment ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Keyon Jie +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/intel_pstate.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/cpufreq/intel_pstate.c ++++ b/drivers/cpufreq/intel_pstate.c +@@ -2570,6 +2570,11 @@ static int intel_pstate_set_policy(struc + intel_pstate_clear_update_util_hook(policy->cpu); + intel_pstate_hwp_set(policy->cpu); + } ++ /* ++ * policy->cur is never updated with the intel_pstate driver, but it ++ * is used as a stale frequency value. So, keep it within limits. ++ */ ++ policy->cur = policy->min; + + mutex_unlock(&intel_pstate_limits_lock); + diff --git a/queue-6.4/sbitmap-fix-batching-wakeup.patch b/queue-6.4/sbitmap-fix-batching-wakeup.patch new file mode 100644 index 00000000000..347afb7d39d --- /dev/null +++ b/queue-6.4/sbitmap-fix-batching-wakeup.patch @@ -0,0 +1,79 @@ +From 106397376c0369fcc01c58dd189ff925a2724a57 Mon Sep 17 00:00:00 2001 +From: David Jeffery +Date: Fri, 21 Jul 2023 17:57:15 +0800 +Subject: sbitmap: fix batching wakeup + +From: David Jeffery + +commit 106397376c0369fcc01c58dd189ff925a2724a57 upstream. + +Current code supposes that it is enough to provide forward progress by +just waking up one wait queue after one completion batch is done. + +Unfortunately this way isn't enough, cause waiter can be added to wait +queue just after it is woken up. + +Follows one example(64 depth, wake_batch is 8) + +1) all 64 tags are active + +2) in each wait queue, there is only one single waiter + +3) each time one completion batch(8 completions) wakes up just one + waiter in each wait queue, then immediately one new sleeper is added + to this wait queue + +4) after 64 completions, 8 waiters are wakeup, and there are still 8 + waiters in each wait queue + +5) after another 8 active tags are completed, only one waiter can be + wakeup, and the other 7 can't be waken up anymore. + +Turns out it isn't easy to fix this problem, so simply wakeup enough +waiters for single batch. + +Cc: Kemeng Shi +Cc: Chengming Zhou +Cc: Jan Kara +Signed-off-by: David Jeffery +Signed-off-by: Ming Lei +Reviewed-by: Gabriel Krisman Bertazi +Reviewed-by: Keith Busch +Link: https://lore.kernel.org/r/20230721095715.232728-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + lib/sbitmap.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/lib/sbitmap.c ++++ b/lib/sbitmap.c +@@ -550,7 +550,7 @@ EXPORT_SYMBOL_GPL(sbitmap_queue_min_shal + + static void __sbitmap_queue_wake_up(struct sbitmap_queue *sbq, int nr) + { +- int i, wake_index; ++ int i, wake_index, woken; + + if (!atomic_read(&sbq->ws_active)) + return; +@@ -567,13 +567,12 @@ static void __sbitmap_queue_wake_up(stru + */ + wake_index = sbq_index_inc(wake_index); + +- /* +- * It is sufficient to wake up at least one waiter to +- * guarantee forward progress. +- */ +- if (waitqueue_active(&ws->wait) && +- wake_up_nr(&ws->wait, nr)) +- break; ++ if (waitqueue_active(&ws->wait)) { ++ woken = wake_up_nr(&ws->wait, nr); ++ if (woken == nr) ++ break; ++ nr -= woken; ++ } + } + + if (wake_index != atomic_read(&sbq->wake_index)) diff --git a/queue-6.4/series b/queue-6.4/series index 08a65ae63aa..a6850f43ca0 100644 --- a/queue-6.4/series +++ b/queue-6.4/series @@ -83,3 +83,6 @@ asoc-cs35l56-add-an-acpi-match-table.patch net-sfp-handle-100g-25g-active-optical-cables-in-sfp.patch tracing-introduce-pipe_cpumask-to-avoid-race-on-trac.patch platform-mellanox-fix-mlxbf-tmfifo-not-handling-all-.patch +sbitmap-fix-batching-wakeup.patch +cpufreq-intel_pstate-set-stale-cpu-frequency-to-minimum.patch +tpm-enable-hwrng-only-for-pluton-on-amd-cpus.patch diff --git a/queue-6.4/tpm-enable-hwrng-only-for-pluton-on-amd-cpus.patch b/queue-6.4/tpm-enable-hwrng-only-for-pluton-on-amd-cpus.patch new file mode 100644 index 00000000000..55aef4c0e37 --- /dev/null +++ b/queue-6.4/tpm-enable-hwrng-only-for-pluton-on-amd-cpus.patch @@ -0,0 +1,82 @@ +From 8f7f35e5aa6f2182eabcfa3abef4d898a48e9aa8 Mon Sep 17 00:00:00 2001 +From: Jarkko Sakkinen +Date: Mon, 4 Sep 2023 21:12:10 +0300 +Subject: tpm: Enable hwrng only for Pluton on AMD CPUs + +From: Jarkko Sakkinen + +commit 8f7f35e5aa6f2182eabcfa3abef4d898a48e9aa8 upstream. + +The vendor check introduced by commit 554b841d4703 ("tpm: Disable RNG for +all AMD fTPMs") doesn't work properly on a number of Intel fTPMs. On the +reported systems the TPM doesn't reply at bootup and returns back the +command code. This makes the TPM fail probe on Lenovo Legion Y540 laptop. + +Since only Microsoft Pluton is the only known combination of AMD CPU and +fTPM from other vendor, disable hwrng otherwise. In order to make sysadmin +aware of this, print also info message to the klog. + +Cc: stable@vger.kernel.org +Fixes: 554b841d4703 ("tpm: Disable RNG for all AMD fTPMs") +Reported-by: Todd Brandt +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217804 +Reported-by: Patrick Steinhardt +Reported-by: Raymond Jay Golo +Reported-by: Ronan Pigott +Reviewed-by: Jerry Snitselaar +Signed-off-by: Jarkko Sakkinen +Cc: Thorsten Leemhuis +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/tpm/tpm_crb.c | 33 ++++++++------------------------- + 1 file changed, 8 insertions(+), 25 deletions(-) + +--- a/drivers/char/tpm/tpm_crb.c ++++ b/drivers/char/tpm/tpm_crb.c +@@ -463,28 +463,6 @@ static bool crb_req_canceled(struct tpm_ + return (cancel & CRB_CANCEL_INVOKE) == CRB_CANCEL_INVOKE; + } + +-static int crb_check_flags(struct tpm_chip *chip) +-{ +- u32 val; +- int ret; +- +- ret = crb_request_locality(chip, 0); +- if (ret) +- return ret; +- +- ret = tpm2_get_tpm_pt(chip, TPM2_PT_MANUFACTURER, &val, NULL); +- if (ret) +- goto release; +- +- if (val == 0x414D4400U /* AMD */) +- chip->flags |= TPM_CHIP_FLAG_HWRNG_DISABLED; +- +-release: +- crb_relinquish_locality(chip, 0); +- +- return ret; +-} +- + static const struct tpm_class_ops tpm_crb = { + .flags = TPM_OPS_AUTO_STARTUP, + .status = crb_status, +@@ -826,9 +804,14 @@ static int crb_acpi_add(struct acpi_devi + if (rc) + goto out; + +- rc = crb_check_flags(chip); +- if (rc) +- goto out; ++#ifdef CONFIG_X86 ++ /* A quirk for https://www.amd.com/en/support/kb/faq/pa-410 */ ++ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD && ++ priv->sm != ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON) { ++ dev_info(dev, "Disabling hwrng\n"); ++ chip->flags |= TPM_CHIP_FLAG_HWRNG_DISABLED; ++ } ++#endif /* CONFIG_X86 */ + + rc = tpm_chip_register(chip); +