[Bug 93294] [BAT SKL] lockdep splat

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93294

--- Comment #10 from Joonas Lahtinen <joonas.lahtinen at linux.intel.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160215/c53ec177/attachment.html>