Messages in this thread Patch in this message | | | Date | Tue, 5 Aug 2014 16:23:41 +0530 | Subject | Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2] | From | Viresh Kumar <> |
| |
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
| |