linux-kernel - Re: [PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

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: <20250721031307.3451012-1-lijiayi@kylinos.cn>
Date: Mon, 21 Jul 2025 11:13:07 +0800
From: Jiayi Li <lijiayi@...inos.cn>
To: rafael@...nel.org
Cc: jiayi_dec@....com,
	lenb@...nel.org,
	lijiayi@...inos.cn,
	linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: Fix initial QoS constraint application order in PPC initialization

>>
>> The original initialization sequence was:
>>
>> cpufreq_policy_online()
>>     acpi_cpufreq_cpu_init()
>>         acpi_processor_get_platform_limit()
>>             freq_qos_update_request(&perflib_req)
>>     blocking_notifier_call_chain(...)
>>         acpi_processor_ppc_init()
>>             freq_qos_add_request(&perflib_req)
>>
>> This caused a race condition where the QoS request was added after the
>> initial platform limit update.
>
>To me, the description above is useless for figuring out what's going on, sorry.
>
>This is not a race, but an ordering issue.
>
>The cpufreq driver calls acpi_processor_register_performance(), which
>among other things causes acpi_processor_get_platform_limit() to be
>called, from its ->init() callback which is invoked by the cpufreq
>core before CPUFREQ_CREATE_POLICY notifiers and the policy frequency
>QoS requests are added by acpi_processor_notifier(), so they don't
>exist when acpi_processor_register_performance() gets called and they
>cannot be updated by the acpi_processor_get_platform_limit().
>
>You want them to be updated as soon as they have been added, which is
>kind of reasonable, but it needs to be done only if
>acpi_processor_register_performance() has been called by the cpufreq
>driver.
>

Sorry, I didn't make the question clear.

This patch fixes an issue where _PPC frequency limits set by the BIOS
failed to take effect due to incorrect call ordering. Previously,
freq_qos_update_request() was being called before freq_qos_add_request(),
causing the constraint updates to be ignored. With this fix, the frequency
limits are now properly enforced as intended.

>> The new sequence explicitly ensures:
>>
>> cpufreq_policy_online()
>>     acpi_cpufreq_cpu_init()
>>         acpi_processor_get_platform_limit()
>>             freq_qos_update_request(&perflib_req)
>>     blocking_notifier_call_chain(...)
>>         acpi_processor_ppc_init()
>>             freq_qos_add_request(&perflib_req)
>> +           acpi_processor_get_platform_limit()
>> +               freq_qos_update_request(&perflib_req)
>>
>> The critical change adds an immediate platform limit update after the
>> QoS request is registered. This guarantees that the initial P-state
>> constraint is applied before any subsequent updates, resolving the window
>> where constraints could be applied out-of-order.
>>
>> Fixes: d15ce412737a ("ACPI: cpufreq: Switch to QoS requests instead of cpufreq notifier")
>> Signed-off-by: Jiayi Li <lijiayi@...inos.cn>
>> ---
>>  drivers/acpi/processor_perflib.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
>> index 64b8d1e19594..3e7fe95c21d1 100644
>> --- a/drivers/acpi/processor_perflib.c
>> +++ b/drivers/acpi/processor_perflib.c
>> @@ -173,6 +173,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
>>  {
>>         unsigned int cpu;
>>
>> +       if (ignore_ppc == 1)
>> +               return;
>> +
>>         for_each_cpu(cpu, policy->related_cpus) {
>>                 struct acpi_processor *pr = per_cpu(processors, cpu);
>>                 int ret;
>
>So AFAICS  this loop needs to check pr->performance in addition to pr.
>

Thanks for the review. I agree and will add a check for pr->performance in v2.

--
lijiayi