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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
