drm/dp/mst: close deadlock in connector destruction.
authorDave Airlie <airlied@redhat.com>
Mon, 15 Jun 2015 00:34:28 +0000 (10:34 +1000)
committerDave Airlie <airlied@redhat.com>
Thu, 25 Jun 2015 01:57:23 +0000 (11:57 +1000)
commit6b8eeca65b18ae77e175cc2b6571731f0ee413bf
treedf8de7144582b43d6e90024dc1a88fc873906499
parent8b72ce158cf0dba443e36fc66e0bb29c2580e0b6
drm/dp/mst: close deadlock in connector destruction.

I've only seen this once, and I failed to capture the
lockdep backtrace, but I did some investigations.

If we are calling into the MST layer from EDID probing,
we have the mode_config mutex held, if during that EDID
probing, the MST hub goes away, then we can get a deadlock
where the connector destruction function in the driver
tries to retake the mode config mutex.

This offloads connector destruction to a workqueue,
and avoid the subsequenct lock ordering issue.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/gpu/drm/drm_dp_mst_topology.c
include/drm/drm_crtc.h
include/drm/drm_dp_mst_helper.h