> >-----Original Message----- > >From: Mathieu Desnoyers [mailto:mathieu.desnoyers@xxxxxxxxxx] > >Sent: Monday, June 01, 2009 12:23 AM > >To: Li, Shaohua > >Cc: davej@xxxxxxxxxx; cpufreq@xxxxxxxxxxxxxxx; rjw@xxxxxxx; mingo@xxxxxxx > >Subject: Re: [BUG]cpufreq_ondemand: a recent regression > > > >* Shaohua Li (shaohua.li@xxxxxxxxx) wrote: > >> commit b14893a62c73af0eca414cfed505b8c09efc613c tries to address a > >lockdep > >> issue, but it introduces new deadlock when doing governor switching. > >> > >> store(lock_policy_rwsem_write)->store_scaling_governor- > >>__cpufreq_set_policy-> > >> cpufreq_governor_dbs->dbs_timer_exit->cancel_delayed_work_sync(hold fake > >work lock) > >> > >> but when the dbs work runs: run_workqueue(hold fake work lock)- > >>do_dbs_timer(lock_policy_rwsem_write) > >> > >> I didn't find an easy way to fix this deadlock, hopes your guys have. > >> > > > >Argh, why is this lock_policy_rwsem_write so pervasive ? It seems like > >it is taken about everywhere before calling any cpufreq code, even when > >not needed. I'd recommend to clearly identify the sites where policy > >modification is done and only take the rwsem _there_. Otherwise, we end > >up in a chicked and egg problem with timer teardown, where we workqueue > >lock has to be taken outside of the read-lock (in the worker thread) and > >inside of the lock (in the rwsem code). > > > >That's really odd. > > The lock_policy inside ondemand is for policy->cur changes and to protect from sysfs changes with max freq or policy->cpus etc. One quick_and_dirty way to resolve it for .30 is to release the rwsem in dbs_timer_exit, then cancel_delayed_work_sync and reacquire the rwsem. That will resolve the deadlock. But, is very very ugly and we need something better for long term. Thanks, Venki -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
