<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [BAT SKL] lockdep splat" href="https://bugs.freedesktop.org/show_bug.cgi?id=93294#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - [BAT SKL] lockdep splat" href="https://bugs.freedesktop.org/show_bug.cgi?id=93294">bug 93294</a> from <a class="email" href="mailto:joonas.lahtinen@linux.intel.com" title="Joonas Lahtinen <joonas.lahtinen@linux.intel.com>"> Joonas Lahtinen</a> <pre>Some further investigation revealed that the using cpu_hotplug.lock for both locking the access to refcount and actual CPU hotplugging section will potentially cause more trouble, so avoiding it in Intel P-state driver is not a good resolution, especially due to measures been taken in the past to make sure get/put_online_cpus can be called recursively. Scenario that goes wrong in a couple of CPUfreq drivers (inlcuding Intel P-state); policy->rwsem is locked during driver initialization and the functions called during init that apply CPU limits use get_online_cpus (because they have other calling paths too), which will briefly lock cpu_hotplug.lock to increase cpu_hotplug.refcount. On the other scenarion when doing a suspend, when cpu_hotplug_begin() is called in the disable_nonboot_cpus(), callbacks to CPUfreq functions get called, which will lock policy->rwsem after holding cpu_hotplug.lock and we do have a potential deadlock scenario (though very unlikely). This is solved by using a lockref for locked reference counting and having a second wait queue for readers during a CPU hotplug operation. I've written a patch that resolves it on my SKL, and set it for comments.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>