linux-kernel - Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency verification

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: <aKwVe4WSG7JApUAi@arm.com>
Date: Mon, 25 Aug 2025 09:49:15 +0200
From: Beata Michalska <beata.michalska@....com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Prashant Malani <pmalani@...gle.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:CPU FREQUENCY SCALING FRAMEWORK" <linux-pm@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH 1/2] cpufreq: Add driver flag to avoid initial frequency
 verification

On Mon, Aug 25, 2025 at 10:26:41AM +0530, Viresh Kumar wrote:
> On 23-08-25, 00:17, Prashant Malani wrote:
> > Some cpufreq drivers have a get() function which can return an unreliable
> > frequency. This can cause issues when switching governors. For instance,
> > a CPU would be on performance governor and have it's frequency (and
> > policy->cur) set to max. When the governor is switched to userspace, the
> > policy->cur is re-used, but it is checked against the frequency returned
> > by the driver's get() function. If it's different, the frequency will
> > get set to the new (incorrect) value.
> > 
> > To avoid this, add a flag that avoids this verify step on governor start
> > if the cpufreq driver opts in to it.
> > 
> > Since there are no users of this flag, no functional changes are
> > introduced here.
> > 
> > Cc: Beata Michalska <beata.michalska@....com>
> > Signed-off-by: Prashant Malani <pmalani@...gle.com>
> > ---
> >  drivers/cpufreq/cpufreq.c |  3 ++-
> >  include/linux/cpufreq.h   | 10 ++++++++++
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index b8937737d096..72e6552a40ea 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2482,7 +2482,8 @@ int cpufreq_start_governor(struct cpufreq_policy *policy)
> >  
> >  	pr_debug("%s: for CPU %u\n", __func__, policy->cpu);
> >  
> > -	cpufreq_verify_current_freq(policy, false);
> > +	if (!(cpufreq_driver->flags & CPUFREQ_DONT_VERIFY_FREQ_ON_GOVERNOR_START))
> > +		cpufreq_verify_current_freq(policy, false);
> 
> I don't think it is okay to do this to hide a driver's failure to
> return the right frequency. What about all the other places where
> get() is still used ? Won't that cause similar issues elsewhere ?
> 
> The driver must be fixed for this, not the core. The core is doing the
Agreed.

---
BR
Beata
> right thing here, asking the driver to return the current frequency.
> If the driver is unsure, it can just return the current frequency from
> policy->cur instead.
> 
> -- 
> viresh