linux-kernel - [PATCH v2] 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: <20250721032606.3459369-1-lijiayi@kylinos.cn>
Date: Mon, 21 Jul 2025 11:26:06 +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: [PATCH v2] ACPI: Fix initial QoS constraint application order in PPC initialization

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 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)

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>
---
v1 -> v2:
- Modify the commit.
- Add pr->performance check in acpi_processor_ppc_init loop.
---
---
 drivers/acpi/processor_perflib.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 64b8d1e19594..56f2b8354d62 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;
@@ -180,6 +183,9 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 		if (!pr)
 			continue;
 
+		if (!pr->performance)
+			continue;
+
 		/*
 		 * Reset performance_platform_limit in case there is a stale
 		 * value in it, so as to make it match the "no limit" QoS value
@@ -193,6 +199,11 @@ void acpi_processor_ppc_init(struct cpufreq_policy *policy)
 		if (ret < 0)
 			pr_err("Failed to add freq constraint for CPU%d (%d)\n",
 			       cpu, ret);
+
+		ret = acpi_processor_get_platform_limit(pr);
+		if (ret)
+			pr_err("Failed to update freq constraint for CPU%d (%d)\n",
+			       cpu, ret);
 	}
 }
 
-- 
2.47.1