MST locking problem?

[Adam Richter]

CONFIG_DEBUG_ATOMIC_SLEEP complains about the following locking problem in linux-4.0-rc1/drivers/gpu/drm/drm_dp_mst_topology.c:
drm_dp_mst_wait_tx_reply --> wait_event_timeout --> check_txmsg_state  --> mutex_lock
I believe that any function called in the "condition" argument in the wait_event_timeout macro (in this case, check_txmsg_state) is not allowed to block when the condition is being evalutated to determine whether to unblock the process.

I think the problem is real.  On two different computers and three different DisplayPort MST hubs, plugging in a DisplayPort hub or having it plugged in from boot time results in a hang within a few minutes of doing a few "xrandr" commands.
At first glance, it looked to me like it might be safe to remove the mutex_{,un}lock calls from check_txmsg_state (which is not called from anywhere else), and change the integer field txmsg->state to be an atomic_t (although I'd be surprised if there is existing hardware that supports an MST hub where the accessing that field is not atomic.  However, altough removing those mutex calls eliminated the complaint from CONFIG_DEBUG_ATOMIC_SLEEP, it also resulted in the system eventually getting a kernel memory fault in the DisplayPort MST code.  So, I need to look at this more carefully.
I'm not stuck in my debugging of this issue at the moment, but wanted to pass along this information to the mailing list now, in case anyone wanted to express some preference regarding the eventual fix or is already dealing with the same problem.
I hope this information is useful.  Thanks in advance for any input.

 Adam Richter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150228/0e8974ed/attachment-0001.html>