Bug ID | 91481 |
---|---|
Summary | [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault |
Product | DRI |
Version | XOrg git |
Hardware | x86 (IA32) |
OS | Linux (All) |
Status | NEW |
Severity | normal |
Priority | medium |
Component | DRM/other |
Assignee | dri-devel@lists.freedesktop.org |
Reporter | adam_richter2004@yahoo.com |
Created attachment 117412 [details]
Path to make drm_dp_send_link_address set link_address_sent before hotplug
handler changes the pointer to it
When I "hot plug" insert a DisplayPort multistream transport ("MST") hub into a
computer that is running a Linux 4.2-rc4 kernel or any recent version, I get a
kernel memory fault in drm_dp_add_port. In earlier kernels, I traced it to the
line after drm_dp_add_port's call to drm_dp_send_link_address:
drm_dp_send_link_address(mstb->mgr, port->mstb);
port->mstb->link_address_sent = true;
I believe that the problem is that drm_dp_send_link_address can call a hotplug
handler, which can change port->mstb so that it cannot be dereferenced (I think
it is set to NULL, but I have forgotten).
Since drm_dp_send_link_address is a static function in this file, its address
is never taken, and there are only two call sites, both of which set
link_address_sent to true, the patch that I have attached changes
drm_dp_send_link_address so that it sets that flag, reducing duplication of
code, and also allowing drm_dp_send_link_address to skip setting the flag if
sending the link address fails.
An intentional behavior change introduced by this patch is that the
mstb->link_address_sent is not set if sending the link address was aborted due
to the memory allocation in drm_dp_send_link_address failing.
Perhaps it should also not be set if the action receives a NAK reply, but I
haven't studied the code and DisplayPort documentation enough to guess.
Whoever examines this patch should feel free to revise it as they see fit.
I should also warn that after I made this change in linux-4.2-rc4, the
resulting kernel eventually got another kernel memory fault in i2c_transfer
(called by drm_do_probe_ddc_edid), but I believe that that is a separate issue.
I am happy to answer questions about this patch. If nobody sees any problems
with it, I would ask that whoever takes this bug report submit the patch
upstream.
Thanks for considering this bug report and proposed patch.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel