[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8763q53ot0.fsf@skyscraper.fehenstaub.lan>
Date: Tue, 12 Aug 2008 23:29:15 +0200
From: Johannes Weiner <hannes@...urebad.de>
To: Nageswara R Sastry <rnsastry@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com,
ego@...ux.vnet.ibm.com, svaidy@...ux.vnet.ibm.com,
davej@...emonkey.org.uk,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Alexey Starikovskiy <alexey.y.starikovskiy@...el.com>
Subject: Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c
Hi Nageswara,
Nageswara R Sastry <rnsastry@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists