diff options
| author | Xiaoguang Chen <chenxg@marvell.com> | 2013-06-19 15:00:07 +0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-04-14 06:42:19 -0700 |
| commit | ba17ca46b968001df16f672ffe694fd0a12512f2 (patch) | |
| tree | 41df62a0206dc89db6b46b979f9eeb53576736b1 /include | |
| parent | 87f93ce8004df49c51813ac113047ac22bced3c9 (diff) | |
| download | linux-3.10-ba17ca46b968001df16f672ffe694fd0a12512f2.tar.gz linux-3.10-ba17ca46b968001df16f672ffe694fd0a12512f2.tar.bz2 linux-3.10-ba17ca46b968001df16f672ffe694fd0a12512f2.zip | |
cpufreq: Fix governor start/stop race condition
commit 95731ebb114c5f0c028459388560fc2a72fe5049 upstream.
Cpufreq governors' stop and start operations should be carried out
in sequence. Otherwise, there will be unexpected behavior, like in
the example below.
Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
to CPU0. The normal sequence is:
1) Current governor is userspace. An application tries to set the
governor to ondemand. It will call __cpufreq_set_policy() in
which it will stop the userspace governor and then start the
ondemand governor.
2) Current governor is userspace. The online of CPU3 runs on CPU0.
It will call cpufreq_add_policy_cpu() in which it will first
stop the userspace governor, and then start it again.
If the sequence of the above two cases interleaves, it becomes:
1) Application stops userspace governor
2) Hotplug stops userspace governor
which is a problem, because the governor shouldn't be stopped twice
in a row. What happens next is:
3) Application starts ondemand governor
4) Hotplug starts a governor
In step 4, the hotplug is supposed to start the userspace governor,
but now the governor has been changed by the application to ondemand,
so the ondemand governor is started once again, which is incorrect.
The solution is to prevent policy governors from being stopped
multiple times in a row. A governor should only be stopped once for
one policy. After it has been stopped, no more governor stop
operations should be executed.
Also add a mutex to serialize governor operations.
[rjw: Changelog. And you owe me a beverage of my choice.]
Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/cpufreq.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 037d36ae63e..1a81b7470bc 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -107,6 +107,7 @@ struct cpufreq_policy { unsigned int policy; /* see above */ struct cpufreq_governor *governor; /* see below */ void *governor_data; + bool governor_enabled; /* governor start/stop flag */ struct work_struct update; /* if update_policy() needs to be * called, but you're in IRQ context */ |