Skip to content

Commit e53ec8a

Browse files
committed
cpufreq: Avoid using inconsistent policy->min and policy->max
JIRA: https://issues.redhat.com/browse/RHEL-83803 commit 7491cdf Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Thu, 17 Apr 2025 17:54:51 +0000 Since cpufreq_driver_resolve_freq() can run in parallel with cpufreq_set_policy() and there is no synchronization between them, the former may access policy->min and policy->max while the latter is updating them and it may see intermediate values of them due to the way the update is carried out. Also the compiler is free to apply any optimizations it wants both to the stores in cpufreq_set_policy() and to the loads in cpufreq_driver_resolve_freq() which may result in additional inconsistencies. To address this, use WRITE_ONCE() when updating policy->min and policy->max in cpufreq_set_policy() and use READ_ONCE() for reading them in cpufreq_driver_resolve_freq(). Moreover, rearrange the update in cpufreq_set_policy() to avoid storing intermediate values in policy->min and policy->max with the help of the observation that their new values are expected to be properly ordered upfront. Also modify cpufreq_driver_resolve_freq() to take the possible reverse ordering of policy->min and policy->max, which may happen depending on the ordering of operations when this function and cpufreq_set_policy() run concurrently, into account by always honoring the max when it turns out to be less than the min (in case it comes from thermal throttling or similar). Fixes: 1517176 ("cpufreq: Make policy min/max hard requirements") Cc: 5.16+ <stable@vger.kernel.org> # 5.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Christian Loehle <christian.loehle@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/5907080.DvuYhMxLoT@rjwysocki.net Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
1 parent 8717091 commit e53ec8a

File tree

1 file changed

+25
-7
lines changed

1 file changed

+25
-7
lines changed

drivers/cpufreq/cpufreq.c

Lines changed: 25 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -539,8 +539,6 @@ static unsigned int __resolve_freq(struct cpufreq_policy *policy,
539539
{
540540
unsigned int idx;
541541

542-
target_freq = clamp_val(target_freq, policy->min, policy->max);
543-
544542
if (!policy->freq_table)
545543
return target_freq;
546544

@@ -564,7 +562,22 @@ static unsigned int __resolve_freq(struct cpufreq_policy *policy,
564562
unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
565563
unsigned int target_freq)
566564
{
567-
return __resolve_freq(policy, target_freq, CPUFREQ_RELATION_LE);
565+
unsigned int min = READ_ONCE(policy->min);
566+
unsigned int max = READ_ONCE(policy->max);
567+
568+
/*
569+
* If this function runs in parallel with cpufreq_set_policy(), it may
570+
* read policy->min before the update and policy->max after the update
571+
* or the other way around, so there is no ordering guarantee.
572+
*
573+
* Resolve this by always honoring the max (in case it comes from
574+
* thermal throttling or similar).
575+
*/
576+
if (unlikely(min > max))
577+
min = max;
578+
579+
return __resolve_freq(policy, clamp_val(target_freq, min, max),
580+
CPUFREQ_RELATION_LE);
568581
}
569582
EXPORT_SYMBOL_GPL(cpufreq_driver_resolve_freq);
570583

@@ -2365,6 +2378,7 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
23652378
if (cpufreq_disabled())
23662379
return -ENODEV;
23672380

2381+
target_freq = clamp_val(target_freq, policy->min, policy->max);
23682382
target_freq = __resolve_freq(policy, target_freq, relation);
23692383

23702384
pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
@@ -2689,11 +2703,15 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
26892703
* Resolve policy min/max to available frequencies. It ensures
26902704
* no frequency resolution will neither overshoot the requested maximum
26912705
* nor undershoot the requested minimum.
2706+
*
2707+
* Avoid storing intermediate values in policy->max or policy->min and
2708+
* compiler optimizations around them because they may be accessed
2709+
* concurrently by cpufreq_driver_resolve_freq() during the update.
26922710
*/
2693-
policy->min = new_data.min;
2694-
policy->max = new_data.max;
2695-
policy->min = __resolve_freq(policy, policy->min, CPUFREQ_RELATION_L);
2696-
policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
2711+
WRITE_ONCE(policy->max, __resolve_freq(policy, new_data.max, CPUFREQ_RELATION_H));
2712+
new_data.min = __resolve_freq(policy, new_data.min, CPUFREQ_RELATION_L);
2713+
WRITE_ONCE(policy->min, new_data.min > policy->max ? policy->max : new_data.min);
2714+
26972715
trace_cpu_frequency_limits(policy);
26982716

26992717
cpufreq_update_pressure(policy);

0 commit comments

Comments
 (0)