linux-kernel - [PATCH] cpufreq: exclude boost frequencies from valid count if not enabled

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

Message-Id: <20210217000013.4063289-1-thara.gopinath@linaro.org>
Date:   Tue, 16 Feb 2021 19:00:13 -0500
From:   Thara Gopinath <thara.gopinath@...aro.org>
To:     rjw@...ysocki.net, viresh.kumar@...aro.org
Cc:     bjorn.andersson@...aro.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: [PATCH] cpufreq: exclude boost frequencies from valid count if not enabled

This is a fix for a regression observed on db845 platforms with 5.7-rc11
kernel.  On these platforms running stress tests with 5.11-rc7 kernel
causes big cpus to overheat and ultimately shutdown the system due to
hitting critical temperature (thermal throttling does not happen and
cur_state of cpufreq cooling device for big cpus remain stuck at 0 or max
frequency).

This platform has boost opp defined for big cpus but boost mode itself is
disabled in the cpufreq driver. Hence the initial max frequency request
from cpufreq cooling device(cur_state) for big cpus is for boost
frequency(2803200) where as initial max frequency request from cpufreq
driver itself is for the highest non boost frequency (2649600). qos
framework collates these two requests and puts the max frequency of big
cpus to 2649600 which the thermal framework is unaware of. Now during an
over heat event, with step-wise policy governor, thermal framework tries to
throttle the cpu and places a restriction on max frequency of the cpu to
cur_state - 1 which in this case 2649600. qos framework in turn tells the
cpufreq cooling device that max frequency of the cpu is already at 2649600
and the cooling device driver returns doing nothing(cur_state of the
cooling device remains unchanged). Thus thermal remains stuck in a loop and
never manages to actually throttle the cpu frequency. This ultimately leads
to system shutdown in case of a thermal overheat event on big cpus.

There are multiple possible fixes for this issue. Fundamentally,it is wrong
for cpufreq driver and cpufreq cooling device driver to show different
maximum possible state/frequency for a cpu. Hence fix this issue by
ensuring that the max state of cpufreq cooling device is in sync with the
maximum frequency of the cpu in cpufreq driver.
cpufreq_table_count_valid_entries is used to retrieve max level/max
frequency of a cpu by cpufreq_cooling_device during initialization. Add
check in this api to ignore boost frequencies if boost mode is not enabled
thus keeping the max state of cpufreq cooling device in sync with the
maximum frequency of the cpu in cpufreq driver.
cpufreq_frequency_table_cpuinfo that calculates the maximum frequency of a
cpu for cpufreq driver already has such a check in place.

Signed-off-by: Thara Gopinath <thara.gopinath@...aro.org>
---
 include/linux/cpufreq.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 9c8b7437b6cd..fe52892e0812 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -1006,8 +1006,11 @@ static inline int cpufreq_table_count_valid_entries(const struct cpufreq_policy
 	if (unlikely(!policy->freq_table))
 		return 0;

-	cpufreq_for_each_valid_entry(pos, policy->freq_table)
+	cpufreq_for_each_valid_entry(pos, policy->freq_table) {
+		if (!cpufreq_boost_enabled() && (pos->flags & CPUFREQ_BOOST_FREQ))
+			continue;
 		count++;
+	}

 	return count;
 }
-- 
2.25.1