linux-kernel - [PATCH v2] cpufreq: intel_pstate: set stale CPU frequency to minimum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <001d01d9d3a7$71736f50$545a4df0$@telus.net>
Date:   Sun, 20 Aug 2023 13:46:49 -0700
From:   "Doug Smythies" <dsmythies@...us.net>
To:     "'Rafael J. Wysocki'" <rafael@...nel.org>,
        "'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>,
        "'Len Brown'" <lenb@...nel.org>
Cc:     "'Thomas Gleixner'" <tglx@...utronix.de>,
        "'Linux PM'" <linux-pm@...r.kernel.org>,
        "'LKML'" <linux-kernel@...r.kernel.org>,
        <yang.jie@...ux.intel.com>, "Doug Smythies" <dsmythies@...us.net>
Subject: [PATCH v2] cpufreq: intel_pstate: set stale CPU frequency to minimum

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 <yang.jie@...ux.intel.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217597
Signed-off-by: Doug Smythies <dsmythies@...us.net>
---

v1 -> v2:
   * v1 was a completely different approach, programming around
     the issue rather than fixing it at the source.
     reference:
     https://patchwork.kernel.org/project/linux-pm/patch/006901d9be8c$f4439930$dccacb90$@telus.net/
   * v2 does not fix an issue with the intel_cpufreq CPU scaling
     driver (A.K.A. the intel_pstate driver in passive mode) and
     the schedutil CPU frequency scaling governor when HWP is enabled
     where limit changes are not reflected in the stale listed frequencies.
     A fix for that will be some future patch.

---
 drivers/cpufreq/intel_pstate.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 8ca2bce4341a..08284dee583a 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2609,6 +2609,11 @@ static int intel_pstate_set_policy(struct cpufreq_policy *policy)
                        intel_pstate_clear_update_util_hook(policy->cpu);
                intel_pstate_hwp_set(policy->cpu);
        }
+       /* policy current 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);

--
2.25.1