Re: [Bug #13475] suspend/hibernate lockdep warning

[Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Mon, Jun 08, 2009 at 08:48:45AM -0400, Mathieu Desnoyers wrote:
 
 > > > >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=13475
 > > > >> Subject         : suspend/hibernate lockdep warning
 > > > >> References      : http://marc.info/?l=linux-kernel&m=124393723321241&w=4
 > > > 
 > > > I suspect the following commit, after revert this patch I test 5 times
 > > > without lockdep warnings.
 > > > 
 > > > commit b14893a62c73af0eca414cfed505b8c09efc613c
 > > > Author: Mathieu Desnoyers <mathieu.desnoyers-scC8bbJcJLCw5LPnMra/2Q@public.gmane.org>
 > > > Date:   Sun May 17 10:30:45 2009 -0400
 > > > 
 > > > 	[CPUFREQ] fix timer teardown in ondemand governor
 > > 
 > > The patch is probably not at fault here. I suspect it's some latent bug
 > > that simply got exposed by the change to cancel_delayed_work_sync(). In
 > > any case, Mathieu, can you take a look at this please?
 > 
 > Yes, it's been looked at and discussed on the cpufreq ML. The short
 > answer is that they plan to re-engineer cpufreq and remove the policy
 > rwlock taken around almost every operations at the cpufreq level.
 > 
 > The short-term solution, which is recognised as ugly, would be do to the
 > following before doing the cancel_delayed_work_sync() :
 > 
 > unlock policy rwlock write lock
 > 
 > lock policy rwlock write lock
 > 
 > It basically works because this rwlock is unneeded for teardown, hence
 > the future re-work planned.
 > 
 > I'm sorry I cannot prepare a patch current... I've got quite a few pages
 > of Ph.D. thesis due for the beginning of July.
 
I'm kinda scared to touch this code at all for .30 due to the number of
unexpected gotchas we seem to run into every time we touch something
locking related.  So I'm inclined to just live with the lockdep warning
for .30, and see how the real fixes look for .31, and push them back
as -stable updates if they work out.


Venki, what are your thoughts?

	Dave