Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[Viresh Kumar <viresh.kumar@linaro.org>]

On 5 August 2014 16:17, Prarit Bhargava <prarit@redhat.com> wrote:
> Nope, not a stupid question.  After reproducing (finally!) yesterday I've been
> wondering the same thing.

Good to know that :)

> I've been looking into *exactly* this.  On any platform where
> cpu_weight(affected_cpus) == 1 for a particular cpu this lockdep trace should
> happen.

> That's what I'm wondering too.  I'm going to instrument the code to find out
> this morning.  I'm wondering if this comes down to a lockdep class issue
> (perhaps lockdep puts globally defined locks like cpufreq_global_kobject in a
> different class?).

Maybe, I tried this Hack to make this somewhat similar to the other case
on my platform with just two CPUs:

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6f02485..6b4abac 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -98,7 +98,7 @@ static DEFINE_MUTEX(cpufreq_governor_mutex);

 bool have_governor_per_policy(void)
 {
-       return !!(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
+       return !(cpufreq_driver->flags & CPUFREQ_HAVE_GOVERNOR_PER_POLICY);
 }
 EXPORT_SYMBOL_GPL(have_governor_per_policy);


This should result in something similar to setting that per-policy-governor
flag (Actually I could have done that too :)), and I couldn't see that crash :(

That needs more investigation now, probably we can get some champ of
sysfs stuff like Tejun/Greg into discussion now..

--
viresh