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

            Bug ID: 92005
           Summary: Linux 4.2 DisplayPort MST deadlock?
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: General
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: adam_richter2004@yahoo.com

In Linux-4.2, there appears to be mutex contention and possible occasionally a
deadlock between two kernel functions, drm_mode_getconnector and
drm_fb_helper_hotplug_event over the mutex dev->mode_config.mutex .  
Neither of these functions is specific to MultiStreamTransport or even
DisplayPort generally, but I think that the DP-MST code might be unique in
causing the contention and deadlock, either due to unanticipated the unusual
tree structure of DP-MST or because of a bug in the DP-MST code.  In
particular, I have at least once observed the following call trace, where I
think drm_mode_getconnector took the mutex, though a long hierarcy of calls,
eventually ended up calling drm_fb_helper_hotplug_event, which tried to take it
again.

I hesitate to open this ticket, because I am not sure that "dev" variable at
the top of this stack trace is the same one as at the bottom, especially
considering that I did not notice the system complaining about attempting to
block on a mutex where mutex->owner == current, even though
CONFIG_DEBUG_MUTEXES was set.  The system that I got this trace from was
blocked infinitely as far as I could tell, which is unusual, in that the
problem that I usually observe has to do with "xrandr" taking on the order of a
minute to complete, and often being inaccurate, but usually not hanging
forever.

I suspect that what happened probably involved some intervening hotplug event
or perhaps involving kernel work functions in a way that I am not completely
clear about where mutex->owner could somehow have been set to the "current" of
a kernel work thread instead of the X server.

Anyhow, the part that I think would likely be helpful to anyone working on this
(and basically the reason I am posting now, rather than waiting) is that this
stack trace might indicate some confusion in assemptions about whether
dev->mode_config.mutex is help by the caller of certain functions in the middle
of this stack trace.

[<ffffffffa01837c8>] drm_fb_helper_hotplug_event+0x138/0x150 [drm_kms_helper]
[<ffffffffa02de31e>] intel_fbdev_output_poll_changed+0x1e/0x30 [i915]
[<ffffffffa017755b>] drm_kms_helper_hotplug_event+0x2b/0x40 [drm_kms_helper]
[<ffffffffa02f1c15>] intel_dp_mst_hotplug+0x15/0x20 [i915]
[<ffffffffa017aef4>] drm_dp_destroy_port+0xd4/0xe0 [drm_kms_helper]
[<ffffffffa017af15>] drm_dp_put_port+0x15/0x20 [drm_kms_helper]
[<ffffffffa017b04e>] drm_dp_destroy_mst_branch_device+0x4e/0x100
[drm_kms_helper]
[<ffffffffa017b115>] drm_dp_put_mst_branch_device+0x15/0x20 [drm_kms_helper]
[<ffffffffa017b6fd>] drm_dp_mst_i2c_xfer+0x9d/0x270 [drm_kms_helper]
[<ffffffff814cca91>] __i2c_transfer+0x121/0x430
[<ffffffff814cce19>] i2c_transfer+0x79/0xb0
[<ffffffffa00bb4a9>] drm_do_probe_ddc_edid+0xc9/0x130 [drm]
[<ffffffffa00bb0fa>] drm_do_get_edid+0x17a/0x250 [drm]
[<ffffffffa00bca55>] drm_get_edid+0x45/0x3d0 [drm]
[<ffffffffa017b9ee>] drm_dp_mst_get_edid+0x7e/0xa0 [drm_kms_helper]
[<ffffffffa02f1c99>] intel_dp_mst_get_modes+0x29/0x50 [i915]
[<ffffffffa0177908>]
drm_helper_probe_single_connector_modes_merge_bits+0x108/0x4e0 [drm_kms_helper]
[<ffffffffa0177cf3>] drm_helper_probe_single_connector_modes+0x13/0x20
[drm_kms_helper]
[<ffffffffa00b6ab9>] drm_mode_getconnector+0x389/0x410 [drm]
[<ffffffffa00a8685>] drm_ioctl+0x1a5/0x670 [drm]
[<ffffffffa00c4e53>] drm_compat_ioctl+0x33/0x40 [drm]
[<ffffffffa026bde2>] i915_compat_ioctl+0x32/0x40 [i915]
[<ffffffff812475f9>] compat_SyS_ioctl+0xc9/0x15d0
[<ffffffff8161ed22>] sysenter_dispatch+0xf/0x29
[<ffffffffffffffff>] 0xffffffffffffffff

I expect that I will update or close this ticket as (or if) I learn more.

I hope this information is helpful.  Comments, and, of course, fixes, are most
welcome.

-- 
You are receiving this mail because:
You are the assignee for the bug.