From: Dave Airlie airlied@redhat.com
The backtrace below shows that while we tear down a branch device, when we remove the connector, we can attempt to disable MST on the port we are tearing down, since the port is going away, there it has a refcount of 0 already, so the validated ref lookup is trying to kref_get again and failing.
Use kref_get_unless_zero and just don't return anything if we are looking up the object we are currently also cleaning.
[<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper] [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper] [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper] [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper] [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper] [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915] [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915] [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915] [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915] [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915] [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915] [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper] [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper] [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper] [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper] [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>] drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>] ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>] ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>] intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>] intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>] i915_digport_work_func+0x96/0x120 [i915]
Signed-off-by: Dave Airlie airlied@redhat.com --- drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ce1113c..f703a5b 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -882,8 +882,10 @@ static struct drm_dp_mst_branch *drm_dp_mst_get_validated_mstb_ref_locked(struct struct drm_dp_mst_port *port; struct drm_dp_mst_branch *rmstb; if (to_find == mstb) { - kref_get(&mstb->kref); - return mstb; + if (!kref_get_unless_zero(&mstb->kref)) + return NULL; + else + return mstb; } list_for_each_entry(port, &mstb->ports, next) { if (port->mstb) {
On Mon, Nov 10, 2014 at 7:41 AM, Dave Airlie airlied@gmail.com wrote:
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ce1113c..f703a5b 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -882,8 +882,10 @@ static struct drm_dp_mst_branch *drm_dp_mst_get_validated_mstb_ref_locked(struct struct drm_dp_mst_port *port; struct drm_dp_mst_branch *rmstb; if (to_find == mstb) {
kref_get(&mstb->kref);return mstb;
if (!kref_get_unless_zero(&mstb->kref))return NULL;elsereturn mstb; } list_for_each_entry(port, &mstb->ports, next) { if (port->mstb) {
kref_get_unless_zero only works with the lookup structure is protected through some locking. But the list removal in drm_dp_destroy_mst_branch_device is outside the mgr->glock, so that needs to be moved I think. That's not directly required by kref_get_unless_zero, just another effect of the ports list not holding a full reference.
Aside for paranoia I'd put a mutex check next to the kref_get_unles_zero, just to document which lock protects this weak reference. And even more tangential: We should probably flatten the recursion, or add a comment stating that the dp spec limits recursion sufficiently. -Daniel
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Dave Airlie