Messages in this thread | | | From | Johannes Weiner <> | Subject | Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c | Date | Tue, 12 Aug 2008 23:29:15 +0200 |
| |
Hi Nageswara,
Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> writes:
> Any updates on this bug.
Sorry. I was just looking into it again and still see no resolution. Added Venkatesh and Alexey to CC.
To summarize again:
The problem we have is that cpufreq_ondemand has a self-rearming worker function which we should but can not cancel synchroneously with the current code. The locking order is like this:
store() policy_rwsem write cpufreq_governor_dbs() dbs_mutex
work lock do_dbs_timer() policy_rwsem write
which gives a locking hierarchy of:
work lock policy_rwsem dbs_mutex
Now, we _should_ cancel the worker synchroneously, but that won't fly since when cpufreq_governor_dbs() is called, we already hold policy_rwsem and grabbing the work lock is illegal.
I will continue to read code and see if I can come up with a solution, but any help is really appreciated.
I have not yet looked at cpufreq_conservative...
> Thanks and Regards > R.Nageswara Sastry
Thanks for your patience and insistence,
Hannes
| |