Re: lockdep warnings: cpufreq ondemand gorvernor possibly circular locking

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

> On Mon, 11 May 2009 00:22:26 +0900 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> 
> > my box output following warnings.
> > it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
> > 
> > A: work -> do_dbs_timer()  -> cpu_policy_rwsem
> > B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
> 
> I can't find any commit which matches
> 7ccc7608b836e58fbacf65ee4f8eefa288e86fac

Grr, sorry. it's mmotm only commit.

filename is cpufreq-fix-timer-teardown-in-ondemand-governor.patch.

commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac
Author: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date:   Tue Apr 28 20:50:21 2009 +0200

    The problem is that dbs_timer_exit() uses cancel_delayed_work() when it
    should use cancel_delayed_work_sync().  cancel_delayed_work() does not
    wait for the workqueue handler to exit.

    The ondemand governor does not "seem" to be affected (read : race
    condition occurs very rarely) because the "if (!dbs_info->enable)" check
    at the beginning of the workqueue handler returns immediately without
    rescheduling the work.  The conservative governor in 2.6.30-rc has the
    same check as the ondemand governor, which makes things usually run
    smoothly.  However, if the governor is quickly stopped and then started,
    this could lead to the following race :

    dbs_enable could be reenabled and multiple do_dbs_timer handlers would
    run.  This is why a synchronized teardown is required.

    The patch applies to, at least, 2.6.28.x, 2.6.29.1, 2.6.30-rc2.