lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Feb 2019 21:32:45 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Lyude Paul <lyude@...hat.com>
Cc:     intel-gfx@...ts.freedesktop.org, David Airlie <airlied@...ux.ie>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Rodrigo Vivi <rodrigo.vivi@...el.com>
Subject: Re: [PATCH v3 2/3] drm/i915: Don't send MST hotplugs during resume

On Tue, Jan 29, 2019 at 02:10:00PM -0500, Lyude Paul wrote:
> We have a bad habit of calling drm_fb_helper_hotplug_event() far more
> then we actually need to. MST appears to be one of these cases, where we
> call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
> topology in intel_dp_mst_resume(). We don't actually need to do this at
> all though since hotplug events are already sent from
> drm_dp_connector_destroy_work() every time connectors are unregistered
> from userspace's PoV. Additionally, extra calls to
> drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
> connector probe somewhere we shouldn't.
> 
> So, don't send any hotplug events during resume if the MST topology
> fails to come up. Just rely on the DP MST helpers to send them for us.
> 
> Signed-off-by: Lyude Paul <lyude@...hat.com>
> Cc: Imre Deak <imre.deak@...el.com>
> Cc: Daniel Vetter <daniel@...ll.ch>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 681e88405ada..c2399acf177b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private *dev_priv)
>  			continue;
>  
>  		ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr);
> -		if (ret)
> -			intel_dp_check_mst_status(intel_dp);
> +		if (ret) {
> +			intel_dp->is_mst = false;
> +			drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
> +							false);

drm_dp_mst_topology_mgr_set_mst()
-> drm_dp_mst_topology_put_mstb()
   -> drm_dp_destroy_mst_branch_device()
      -> drm_dp_mst_topology_put_port()
         -> drm_dp_destroy_port()
	    -> drm_dp_destroy_connector_work()
	       -> drm_kms_helper_hotplug_event()

That of course requires that no one is hanging on to the
kref(s). The lifetime of the references isn't really clear
to me, but I'll take your word that it works.

Reviewed-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>

> +		}
>  	}
>  }
> -- 
> 2.20.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ