Messages in this thread | | | Date | Thu, 11 Feb 2016 10:48:20 +0100 | Subject | Re: [PATCH V4 2/7] cpufreq: Call __cpufreq_governor() with policy->rwsem held | From | "Rafael J. Wysocki" <> |
| |
On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > This isn't followed properly by all parts of the core code, some follow > it, whereas others don't.
"The cpufreq core code is not consistent with respect to invoking __cpufreq_governor() under policy->rwsem."
> Enforcing it will also enable us to remove cpufreq_governor_lock, that > is used today because we can't guarantee that __cpufreq_governor() isn't > executed in parallel.
"Changing all code to always hold policy->rwsem around __cpufreq_governor() invocations will allow us to ..."
> We should also ensure that the lock is held across state changes to the > governors. > > For example, while adding a CPU to the policy on 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 > execute without any concurrent races. And that can be achieved using > policy->rwsem around these use cases. > > Also note that cpufreq_driver->stop_cpu() and ->exit() can get called > while policy->rwsem is held. That shouldn't have any side effects > though.
The last paragraph is unclear.
Is it supposed to mean that the change will cause cpufreq_driver->stop_cpu() and ->exit() to be called under policy->rwsem sometimes?
Thanks, Rafael
| |