diff options
author | Viresh Kumar <viresh.kumar@linaro.org> | 2016-02-11 15:01:12 +0300 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2016-03-09 16:41:00 +0300 |
commit | 49f18560f8bac5315047edfb673dd13d56cbcbc9 (patch) | |
tree | 994561aa9879b8392b460bbf4cd969dacbd7ffe5 /drivers/cpufreq/cpufreq_governor.h | |
parent | 69cee7147b4a4ea02085d571cd2d9974d4a4d8d5 (diff) | |
download | linux-49f18560f8bac5315047edfb673dd13d56cbcbc9.tar.xz |
cpufreq: Call __cpufreq_governor() with policy->rwsem held
The cpufreq core code is not consistent with respect to invoking
__cpufreq_governor() under policy->rwsem.
Changing all code to always hold policy->rwsem around
__cpufreq_governor() invocations will allow us to remove
cpufreq_governor_lock that is used today because we can't
guarantee that __cpufreq_governor() isn't executed twice in
parallel for the same policy.
We should also ensure that policy->rwsem is held across governor
state changes.
For example, while adding a CPU to the policy in the CPU online path,
we need to stop the governor, change policy->cpus, start the governor
and then refresh its limits. The complete sequence must be guaranteed
to complete without interruptions by concurrent governor state
updates. That can be achieved by holding policy->rwsem around those
sequences of operations.
Also note that after this patch cpufreq_driver->stop_cpu() and
->exit() will get called under policy->rwsem which wasn't the case
earlier. That shouldn't have any side effects, though.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Juri Lelli <juri.lelli@arm.com>
Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq/cpufreq_governor.h')
0 files changed, 0 insertions, 0 deletions