linux.git/drivers/thermal/cpu_cooling.c, branch v4.9.209

thermal: cpu_cooling: Avoid accessing potentially freed structures

2017-07-27T22:07:55+00:00

commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream.

After the lock is dropped, it is possible that the cpufreq_dev gets
freed before we call get_level() and that can cause kernel to crash.

Drop the lock after we are done using the structure.

Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling")
Signed-off-by: Viresh Kumar 
Reviewed-by: Lukasz Luba 
Tested-by: Lukasz Luba 
Signed-off-by: Eduardo Valentin 
Signed-off-by: Greg Kroah-Hartman

thermal: cpu_cooling: Fix wrong comment call function name

2016-09-27T01:38:17+00:00

The last_load is updated not cpufreq_get_actual_power() function call
but cpufreq_get_requested_power() function call.

Signed-off-by: Inhyuk Kang 
Acked-by: Viresh Kumar 
Acked-by: Javi Merino 
Acked-by: Javi Merino 
Signed-off-by: Zhang Rui

thermal: cpu_cooling: Fix NULL dereference in cpufreq_state2power

2016-08-19T13:32:18+00:00

Currently all CPU cooling devices share a
`struct thermal_cooling_device_ops` instance. The thermal core uses the
presence of functions in this struct to determine if a cooling device
has a power model (see cdev_is_power_actor). cpu_cooling.c adds the
power model functions to the shared struct when a device is registered
with a power model.

Therefore, if a CPU cooling device is registered using
[of_]cpufreq_power_cooling_register, _all_ devices will be determined to
have a power model, including any registered with
[of_]cpufreq_cooling_register. This can result in cpufreq_state2power
being called on a device where dyn_power_table is NULL.

With this commit, instead of having a shared thermal_cooling_device_ops
which is mutated, we have two versions: one with the power functions and
one without.

Signed-off-by: Brendan Jackman 
Cc: Amit Daniel Kachhap 
Cc: Viresh Kumar 
Cc: Javi Merino 
Acked-by: Viresh Kumar 
Acked-by: Javi Merino 
Signed-off-by: Zhang Rui

Merge back earlier cpufreq changes for v4.8.

2016-06-13T21:33:17+00:00

cpufreq: Remove cpufreq_frequency_get_table()

2016-06-08T22:58:05+00:00

Most of the callers of cpufreq_frequency_get_table() already have the
pointer to a valid 'policy' structure and they don't really need to go
through the per-cpu variable first and then a check to validate the
frequency, in order to find the freq-table for the policy.

Directly use the policy->freq_table field instead for them.

Only one user of that API is left after above changes, cpu_cooling.c and
it accesses the freq_table in a racy way as the policy can get freed in
between.

Fix it by using cpufreq_cpu_get() properly.

Since there are no more users of cpufreq_frequency_get_table() left, get
rid of it.

Signed-off-by: Viresh Kumar 
Acked-by: Javi Merino  (cpu_cooling.c)
Signed-off-by: Rafael J. Wysocki

thermal: cpu_cooling: fix improper order during initialization

2016-06-01T14:21:19+00:00

The freq_table array is not populated before calling
thermal_of_cooling_register. The code which populates the freq table was
introduced in commit f6859014.
This should be done before registering new thermal cooling device.
The log shows effects of this wrong decision.
[    2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34
[    2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34

Cc:  # 3.19+
Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
Signed-off-by: Lukasz Luba 
Acked-by: Javi Merino 
Acked-by: Viresh Kumar 
Signed-off-by: Zhang Rui

thermal: cpu_cooling: fix out of bounds access in time_in_idle

2016-02-11T15:13:29+00:00

In __cpufreq_cooling_register() we allocate the arrays for time_in_idle
and time_in_idle_timestamp to be as big as the number of cpus in this
cpufreq device.  However, in get_load() we access this array using the
cpu number as index, which can result in an out of bound access.

Index time_in_idle{,_timestamp} using the index in the cpufreq_device's
allowed_cpus mask, as we do for the load_cpu array in
cpufreq_get_requested_power()

Reported-by: Nicolas Boichat 
Cc: Amit Daniel Kachhap 
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Tested-by: Nicolas Boichat 
Acked-by: Viresh Kumar 
Signed-off-by: Javi Merino 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: Remove usage of devm functions

2015-10-10T03:32:21+00:00

In the function cpufreq_get_requested_power, the memory allocated
for load_cpu is live within the function only. And after the
allocation it is immediately freed with devm_kfree. There is no
need to allocate memory for load_cpu with devm function so replace
devm_kcalloc with kcalloc and devm_kfree with kfree.

Signed-off-by: Vaishali Thakkar 
Acked-by: Viresh Kumar 
Acked-by: Javi Merino 
Signed-off-by: Zhang Rui

thermal: cpu_cooling: free power table on error or when unregistering

2015-09-14T03:34:05+00:00

The power table is not being freed on error from cpufreq_cooling
register or when unregistering.  Free it.

Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API")
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Javi Merino 
Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: don't call kcalloc() under rcu_read_lock

2015-09-14T03:33:17+00:00

build_dyn_power_table() allocates the power table while holding
rcu_read_lock.  kcalloc using GFP_KERNEL may sleep, so it can't be
called in an RCU read-side path.

Move the rcu protection to the part of the function that really needs
it: the part that handles the dev_pm_opp pointer received from
dev_pm_opp_find_freq_ceil().  In the unlikely case that there is an OPP
added to the cpu while this function is running, return -EAGAIN.

Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API")
Cc: Zhang Rui 
Cc: Eduardo Valentin 
Signed-off-by: Javi Merino 
Signed-off-by: Eduardo Valentin