* 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. Mathieu > Thanks, > Shaohua -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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
