Re: [PATCH v2] drm/i915: Cancel the hotplug work when unregistering the connector

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Op 09-10-17 om 11:59 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2017-10-09 10:41:29)
>> Op 06-10-17 om 19:18 schreef Chris Wilson:
>>> When we unregister the connector, we may have a pending hotplug work.
>>> This needs to be cancel early during the teardown so that it does not
>>> fire after we have freed the connector. Or else we may see something like:
>> Well the nice thing is even if it's called modeset_retry_work, it just sets the link status to bad for DP.
> Ok, and sends a hotplug event. At what point in the shutdown sequence
> does that drm_kms_helper_hotplug_event() become invalid?
Some digging makes me suspect at the very end of driver unload. So for this either is fine. But after some more digging, it's not enough, see below.
>> I worry it might be too early, wouldn't intel_dp_connector_destroy be a better place? At that point we know userspace can no longer use it,
>> because the last reference has been removed.
> connector_destroy is after drm_kms_helper_poll_fini(), so that seems
> suspect given a query about drm_kms_helper_hotplug_event()
>
> A hook from drm_atomic_helper_shutdown? Extending unregister to have a
> late phase?
>
Well after some more digging the only case where early_unregister vs unregister matters is DP-MST, where we can lose connectors dynamically.
As long as we never use modeset_retry_work on DP-MST connectors, everything is fine. Fortunately we don't do that, only used in DP connectors for now.

But if you look at the backtrace, the first error is from intel_fbdev_fini, so we need to cancel the work after poll_fini, and before fbdev_fini.

Fixing it in early_unregister is simply too late..

~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx