[Intel-gfx] [PATCH v3.1 3/3] drm/i915: Don't try to remove MST cleanly when force removed.

[Daniel Vetter]

On Thu, Aug 06, 2015 at 03:51:31PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 06-08-15 om 15:01 schreef Daniel Vetter:
> > On Thu, Aug 06, 2015 at 01:47:37PM +0200, Maarten Lankhorst wrote:
> >> Physically disconnecting a DP connector with an active MST stream
> >> can lead to a kernel panic in intel_mst_disable_dp when calling
> >> drm_dp_update_payload_part1. Examining the code it seems that the
> >> port is freed while work to remove the connector is scheduled.
> >>
> >> This probably means it's fine to skip call all the mst helper calls
> >> and only attempt to disable the real encoder.
> > I think this is a refcounting bug in the dp mst helpers, the port
> > shouldn't just go poof when we still hold a reference to it. Can you
> > please try to figure out what's really broken here, and if that's too
> > tricky add a big FIXME comment?
> Look at drm_dp_destroy_port, it calls schedule_work(&mgr->destroy_connector_work), and also calls kfree(port).
> 
> Doesn't look like a refcounting bug to me, more like something intentional.

Intentionally buggy is still buggy ;-)

And yeah we probably need to separate the port cleanup due to unplug (i.e.
the driver callback) from freeing the port. And the intel_connector should
hold a reference onto the underlying port I think. Of course it would be
best to do the get/put on the port in the mst helper itself (so that we
don't need to change i915/radeon).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch