linux-kernel - Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set target

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

Date: Thu, 30 May 2024 09:06:43 +0800
From: Riwen Lu <luriwen@...mail.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: rafael@...nel.org, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, Riwen Lu <luriwen@...inos.cn>
Subject: Re: [PATCH v2] cpufreq/cppc: Take policy->cur into judge when set
 target

在 2024/5/29 15:12, Viresh Kumar 写道:
> On 29-05-24, 14:53, Riwen Lu wrote:
>> Yes, you are right， I didn't think it through. In this circumstance, the
>> policy->cur is the highest frequency, desired_perf converted from
>> target_freq is the same with cpu_data->perf_ctrls.desired_perf which
>> shouldn't.
> 
> Please investigate more and see where the real problem is.
> 
The boot CPU's frequency would be configured to the highest perf when 
powered on from S3 even though the policy governor is powersave.

In cpufreq resume process, the booting CPU's new_freq obtained via 
get() is the highest frequency, while the policy->cur and 
cpu->perf_ctrls.desired_perf are in the lowest level(powersave 
governor). Causing the warning: "CPU frequency out of sync:", and set 
policy->cur to new_freq. Then the governor->limits() calls 
cppc_cpufreq_set_target() to configures the CPU frequency and returns 
directly because the desired_perf converted from target_freq and 
cpu->perf_ctrls.desired_perf are the same and both are the lowest_perf.

The problem is that the cpu->perf_ctrls.desired_perf is the lowest_perf 
but it should be the highest_perf.

In my opinion, desired_perf and cpu->perf_ctrls.desired_perf represent 
the target_freq and policy->cur respectively. Since target_freq and 
policy->cur have been compared in __cpufreq_driver_target(), there's no 
need to compare desired_perf and cpu->perf_ctrls.desired_perf again in 
cppc_cpufreq_set_target().
So, maybe we can remove the following logic in cppc_cpufreq_set_target().
/* Return if it is exactly the same perf */
if (desired_perf == cpu_data->perf_ctrls.desired_perf)
	return ret;