Revision b5d281f6c16dd432b618bdfd36ddba1a58d5b603 authored by Christian Marangi on 19 June 2022, 22:03:51 UTC, committed by Chanwoo Choi on 29 June 2022, 20:11:17 UTC
On a devfreq PROBE_DEFER, the freq_table in the driver profile struct, is never reset and may be leaved in an undefined state. This comes from the fact that we store the freq_table in the driver profile struct that is commonly defined as static and not reset on PROBE_DEFER. We currently skip the reinit of the freq_table if we found it's already defined since a driver may declare his own freq_table. This logic is flawed in the case devfreq core generate a freq_table, set it in the profile struct and then PROBE_DEFER, freeing the freq_table. In this case devfreq will found a NOT NULL freq_table that has been freed, skip the freq_table generation and probe the driver based on the wrong table. To fix this and correctly handle PROBE_DEFER, use a local freq_table and max_state in the devfreq struct and never modify the freq_table present in the profile struct if it does provide it. Fixes: 0ec09ac2cebe ("PM / devfreq: Set the freq_table of devfreq device") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
1 parent f44b799
File | Mode | Size |
---|---|---|
policy | ||
.gitignore | -rw-r--r-- | 71 bytes |
Kconfig | -rw-r--r-- | 3.3 KB |
Makefile | -rw-r--r-- | 810 bytes |
audit.c | -rw-r--r-- | 12.4 KB |
common.c | -rw-r--r-- | 75.8 KB |
common.h | -rw-r--r-- | 40.2 KB |
condition.c | -rw-r--r-- | 27.1 KB |
domain.c | -rw-r--r-- | 25.4 KB |
environ.c | -rw-r--r-- | 3.1 KB |
file.c | -rw-r--r-- | 29.2 KB |
gc.c | -rw-r--r-- | 16.6 KB |
group.c | -rw-r--r-- | 5.8 KB |
load_policy.c | -rw-r--r-- | 2.6 KB |
memory.c | -rw-r--r-- | 5.4 KB |
mount.c | -rw-r--r-- | 6.7 KB |
network.c | -rw-r--r-- | 21.5 KB |
realpath.c | -rw-r--r-- | 7.3 KB |
securityfs_if.c | -rw-r--r-- | 7.4 KB |
tomoyo.c | -rw-r--r-- | 15.7 KB |
util.c | -rw-r--r-- | 27.6 KB |
Computing file changes ...