linux-kernel - Re: [PATCH] cpufreq: cap the default transition delay at 10 ms

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-prev] [day] [month] [year] [list]

Message-ID: <aMjC-BHKXjZkFmvj@dragon>
Date: Tue, 16 Sep 2025 09:52:56 +0800
From: Shawn Guo <shawnguo2@...h.net>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Qais Yousef <qyousef@...alina.io>,
	Viresh Kumar <viresh.kumar@...aro.org>, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Shawn Guo <shawnguo@...nel.org>,
	stable@...r.kernel.org
Subject: Re: [PATCH] cpufreq: cap the default transition delay at 10 ms

On Mon, Sep 15, 2025 at 03:18:44PM +0200, Rafael J. Wysocki wrote:
> The question is not about who's fault it is, but what's the best place
> to address this issue.
> 
> I think that addressing it in cpufreq_policy_transition_delay_us() is
> a bit confusing because it is related to initialization and the new
> branch becomes pure overhead for the drivers that don't set
> cpuinfo.transition_latency to CPUFREQ_ETERNAL.
> 
> However, addressing it at the initialization time would effectively
> mean that the core would do something like:
> 
> if (policy->cpuinfo.transition_latency == CPUFREQ_ETERNAL)
>         policy->cpuinfo.transition_latency =
> CPUFREQ_DEFAULT_TANSITION_LATENCY_NS;
> 
> but then it would be kind of more straightforward to update everybody
> using CPUFREQ_ETERNAL to set cpuinfo.transition_latency to
> CPUFREQ_DEFAULT_TANSITION_LATENCY_NS directly (and then get rid of
> CPUFREQ_ETERNAL entirely).

So we fix the regression with an immediate change like below, and then
plan to remove CPUFREQ_ETERNAL entirely with another development series.
Do I get you right?

---8<---

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index d873ff9add49..e37722ce7aec 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -574,6 +574,10 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy)
        if (policy->transition_delay_us)
                return policy->transition_delay_us;
 
+       if (policy->cpuinfo.transition_latency == CPUFREQ_ETERNAL)
+               policy->cpuinfo.transition_latency =
+                       CPUFREQ_DEFAULT_TANSITION_LATENCY_NS;
+
        latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
        if (latency)
                /*
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 7fe0981a7e46..7331bc06f161 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -36,6 +36,8 @@
 /* Print length for names. Extra 1 space for accommodating '\n' in prints */
 #define CPUFREQ_NAME_PLEN              (CPUFREQ_NAME_LEN + 1)
 
+#define CPUFREQ_DEFAULT_TANSITION_LATENCY_NS   NSEC_PER_MSEC
+
 struct cpufreq_governor;
 
 enum cpufreq_table_sorting {

--->8---

Shawn