linux-kernel - Re: [PATCH v1 2/3] cpufreq: Always enforce policy limits even without frequency table

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]

Message-ID: <e91bd1e9-8db4-4923-92fe-52893623487e@kylinos.cn>
Date: Thu, 4 Sep 2025 13:48:00 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J . wysocki" <rafael@...nel.org>,
 Saravana Kannan <saravanak@...gle.com>, zhenglifeng
 <zhenglifeng1@...wei.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/3] cpufreq: Always enforce policy limits even without
 frequency table

在 2025/9/4 13:37, Viresh Kumar 写道:
> On 04-09-25, 13:23, Zihuan Zhang wrote:
>> 在 2025/9/4 12:48, Viresh Kumar 写道:
>>> On 04-09-25, 11:22, Zihuan Zhang wrote:
>>>>    int cpufreq_generic_frequency_table_verify(struct cpufreq_policy_data *policy)
>>>>    {
>>>> +	cpufreq_verify_within_cpu_limits(policy);
>>> So if we have a freq-table, we will call this twice now. Why make it
>>> bad for the existing users ?
>>
>> Just to clarify, in the third patch of this series we remove
>> cpufreq_generic_frequency_table_verify() from the table_verify path,
>> so cpufreq_verify_within_cpu_limits() is now only called here. There
>> won’t be any duplicate invocation for drivers that already have a
>> frequency table.
> Maybe I wasn't clear enough.
>
> int cpufreq_frequency_table_verify(...)
> {
> 	cpufreq_verify_within_cpu_limits(...);
>          ...
> }
>
> int cpufreq_generic_frequency_table_verify(...)
> {
>          cpufreq_verify_within_cpu_limits(...);
>          cpufreq_frequency_table_verify(...);
>          ...
> }
>
> For a driver with a valid freq-table, we will call
> cpufreq_verify_within_cpu_limits() unnecessarily, isn't it ?

I understand your point about the potential duplicate call to
cpufreq_verify_within_cpu_limits() for drivers with a valid freq-table.
However, in the third patch of this series, we removed the call to
cpufreq_generic_frequency_table_verify() from the table_verify path.

In the Third patch:

-int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
+static int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
  {
  	struct cpufreq_frequency_table *pos, *table = policy->freq_table;
  	unsigned int freq, prev_smaller = 0;
@@ -73,8 +73,6 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
  	pr_debug("request for verification of policy (%u - %u kHz) for cpu %u\n",
  					policy->min, policy->max, policy->cpu);

-	cpufreq_verify_within_cpu_limits(policy);
-
  	cpufreq_for_each_valid_entry(pos, table) {

Now, the verification and the CPU limits check are unified in the
generic function, so there is no longer a redundant invocation for
drivers with a frequency table.

Thanks!