From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault Date: Tue, 28 Jul 2015 05:18:27 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0809715320==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 5C2B86E210 for ; Mon, 27 Jul 2015 22:18:27 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0809715320== Content-Type: multipart/alternative; boundary="1438060707.2ebdCFf0.7759"; charset="UTF-8" --1438060707.2ebdCFf0.7759 Date: Tue, 28 Jul 2015 05:18:27 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=91481 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 --> https://bugs.freedesktop.org/attachment.cgi?id=117412&action=edit 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. --1438060707.2ebdCFf0.7759 Date: Tue, 28 Jul 2015 05:18:27 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"
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.
--1438060707.2ebdCFf0.7759-- --===============0809715320== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============0809715320==--