From: Sean Paul <sean@poorly.run>
To: Ramalingam C <ramalingam.c@intel.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
Sean Paul <seanpaul@chromium.org>,
dri-devel@lists.freedesktop.org, rodrigo.vivi@intel.com,
Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v2 07/12] drm/i915: Protect workers against disappearing connectors
Date: Fri, 13 Dec 2019 14:04:41 -0500 [thread overview]
Message-ID: <20191213190441.GF41609@art_vandelay> (raw)
In-Reply-To: <20191213111033.GF3829@intel.com>
On Fri, Dec 13, 2019 at 04:40:33PM +0530, Ramalingam C wrote:
> On 2019-12-12 at 14:02:25 -0500, Sean Paul wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds some protection against connectors being destroyed
> > before the HDCP workers are finished.
> >
> > For check_work, we do a synchronous cancel after the connector is
> > unregistered which will ensure that it is finished before destruction.
> >
> > In the case of prop_work, we can't do a synchronous wait since it needs
> > to take connection_mutex which could cause deadlock. Instead, we'll take
> > a reference on the connector when scheduling prop_work and give it up
> > once we're done.
> >
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Will there be an instance where prop_work is scheduled but before
> execution cancelled from the queue itself? This will leak the connector
> reference.
No, prop_work is really quite simple, it just grabs some locks and updates the
property value.
>
> Atleast hdcp stack is not requesting for such action. So Looks good to me.
>
> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Thanks, I'm going to dig into what we should do when hdcp_cleanup is called from
connector_init failure paths and revise this patch.
> >
> > Changes in v2:
> > - Added to the set
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 38 ++++++++++++++++++++---
> > 1 file changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 798e7e1a19fc..c79dca2c74d1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -863,8 +863,10 @@ static void intel_hdcp_update_value(struct intel_connector *connector,
> > return;
> >
> > hdcp->value = value;
> > - if (update_property)
> > + if (update_property) {
> > + drm_connector_get(&connector->base);
> > schedule_work(&hdcp->prop_work);
> > + }
> > }
> >
> > /* Implements Part 3 of the HDCP authorization procedure */
> > @@ -954,6 +956,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
> >
> > mutex_unlock(&hdcp->mutex);
> > drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > +
> > + drm_connector_put(&connector->base);
> > }
> >
> > bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
> > @@ -1802,6 +1806,9 @@ static void intel_hdcp_check_work(struct work_struct *work)
> > check_work);
> > struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
> >
> > + if (drm_connector_is_unregistered(&connector->base))
> > + return;
> > +
> > if (!intel_hdcp2_check_link(connector))
> > schedule_delayed_work(&hdcp->check_work,
> > DRM_HDCP2_CHECK_PERIOD_MS);
> > @@ -2076,12 +2083,33 @@ void intel_hdcp_component_fini(struct drm_i915_private *dev_priv)
> >
> > void intel_hdcp_cleanup(struct intel_connector *connector)
> > {
> > - if (!connector->hdcp.shim)
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > +
> > + if (!hdcp->shim)
> > return;
> >
> > - mutex_lock(&connector->hdcp.mutex);
> > - kfree(connector->hdcp.port_data.streams);
> > - mutex_unlock(&connector->hdcp.mutex);
> > + WARN_ON(!drm_connector_is_unregistered(&connector->base));
> > +
> > + /*
> > + * Now that the connector is unregistered, check_work won't be run, but
> > + * cancel any outstanding instances of it
> > + */
> > + cancel_delayed_work_sync(&hdcp->check_work);
> > +
> > + /*
> > + * We don't cancel prop_work in the same way as check_work since it
> > + * requires connection_mutex which could be held while calling this
> > + * function. Instead, we rely on the connector references grabbed before
> > + * scheduling prop_work to ensure the connector is alive when prop_work
> > + * is run. So if we're in the destroy path (which is where this
> > + * function should be called), we're "guaranteed" that prop_work is not
> > + * active (tl;dr This Should Never Happen).
> > + */
> > + WARN_ON(work_pending(&hdcp->prop_work));
> > +
> > + mutex_lock(&hdcp->mutex);
> > + kfree(hdcp->port_data.streams);
> > + mutex_unlock(&hdcp->mutex);
> > }
> >
> > void intel_hdcp_atomic_check(struct drm_connector *connector,
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Sean Paul <sean@poorly.run>
To: Ramalingam C <ramalingam.c@intel.com>
Cc: daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org,
Sean Paul <seanpaul@chromium.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 07/12] drm/i915: Protect workers against disappearing connectors
Date: Fri, 13 Dec 2019 14:04:41 -0500 [thread overview]
Message-ID: <20191213190441.GF41609@art_vandelay> (raw)
In-Reply-To: <20191213111033.GF3829@intel.com>
On Fri, Dec 13, 2019 at 04:40:33PM +0530, Ramalingam C wrote:
> On 2019-12-12 at 14:02:25 -0500, Sean Paul wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds some protection against connectors being destroyed
> > before the HDCP workers are finished.
> >
> > For check_work, we do a synchronous cancel after the connector is
> > unregistered which will ensure that it is finished before destruction.
> >
> > In the case of prop_work, we can't do a synchronous wait since it needs
> > to take connection_mutex which could cause deadlock. Instead, we'll take
> > a reference on the connector when scheduling prop_work and give it up
> > once we're done.
> >
> > Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Will there be an instance where prop_work is scheduled but before
> execution cancelled from the queue itself? This will leak the connector
> reference.
No, prop_work is really quite simple, it just grabs some locks and updates the
property value.
>
> Atleast hdcp stack is not requesting for such action. So Looks good to me.
>
> Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Thanks, I'm going to dig into what we should do when hdcp_cleanup is called from
connector_init failure paths and revise this patch.
> >
> > Changes in v2:
> > - Added to the set
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 38 ++++++++++++++++++++---
> > 1 file changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 798e7e1a19fc..c79dca2c74d1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -863,8 +863,10 @@ static void intel_hdcp_update_value(struct intel_connector *connector,
> > return;
> >
> > hdcp->value = value;
> > - if (update_property)
> > + if (update_property) {
> > + drm_connector_get(&connector->base);
> > schedule_work(&hdcp->prop_work);
> > + }
> > }
> >
> > /* Implements Part 3 of the HDCP authorization procedure */
> > @@ -954,6 +956,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
> >
> > mutex_unlock(&hdcp->mutex);
> > drm_modeset_unlock(&dev->mode_config.connection_mutex);
> > +
> > + drm_connector_put(&connector->base);
> > }
> >
> > bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
> > @@ -1802,6 +1806,9 @@ static void intel_hdcp_check_work(struct work_struct *work)
> > check_work);
> > struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
> >
> > + if (drm_connector_is_unregistered(&connector->base))
> > + return;
> > +
> > if (!intel_hdcp2_check_link(connector))
> > schedule_delayed_work(&hdcp->check_work,
> > DRM_HDCP2_CHECK_PERIOD_MS);
> > @@ -2076,12 +2083,33 @@ void intel_hdcp_component_fini(struct drm_i915_private *dev_priv)
> >
> > void intel_hdcp_cleanup(struct intel_connector *connector)
> > {
> > - if (!connector->hdcp.shim)
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > +
> > + if (!hdcp->shim)
> > return;
> >
> > - mutex_lock(&connector->hdcp.mutex);
> > - kfree(connector->hdcp.port_data.streams);
> > - mutex_unlock(&connector->hdcp.mutex);
> > + WARN_ON(!drm_connector_is_unregistered(&connector->base));
> > +
> > + /*
> > + * Now that the connector is unregistered, check_work won't be run, but
> > + * cancel any outstanding instances of it
> > + */
> > + cancel_delayed_work_sync(&hdcp->check_work);
> > +
> > + /*
> > + * We don't cancel prop_work in the same way as check_work since it
> > + * requires connection_mutex which could be held while calling this
> > + * function. Instead, we rely on the connector references grabbed before
> > + * scheduling prop_work to ensure the connector is alive when prop_work
> > + * is run. So if we're in the destroy path (which is where this
> > + * function should be called), we're "guaranteed" that prop_work is not
> > + * active (tl;dr This Should Never Happen).
> > + */
> > + WARN_ON(work_pending(&hdcp->prop_work));
> > +
> > + mutex_lock(&hdcp->mutex);
> > + kfree(hdcp->port_data.streams);
> > + mutex_unlock(&hdcp->mutex);
> > }
> >
> > void intel_hdcp_atomic_check(struct drm_connector *connector,
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-12-13 20:59 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 19:02 [PATCH v2 00/12] drm/i915: Add support for HDCP 1.4 over MST connectors Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-12 19:02 ` [PATCH v2 01/12] drm/i915: Fix sha_text population code Sean Paul
2019-12-12 19:02 ` Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 10:20 ` Ramalingam C
2019-12-13 10:20 ` Ramalingam C
2019-12-13 10:20 ` [Intel-gfx] " Ramalingam C
2019-12-12 19:02 ` [PATCH v2 02/12] drm/i915: Clear the repeater bit on HDCP disable Sean Paul
2019-12-12 19:02 ` Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 10:29 ` Ramalingam C
2019-12-13 10:29 ` Ramalingam C
2019-12-13 10:29 ` [Intel-gfx] " Ramalingam C
2019-12-13 19:07 ` Sean Paul
2019-12-13 19:07 ` Sean Paul
2019-12-13 19:07 ` [Intel-gfx] " Sean Paul
2019-12-12 19:02 ` [PATCH v2 03/12] drm/i915: WARN if HDCP signalling is enabled upon disable Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 10:37 ` Ramalingam C
2019-12-13 10:37 ` [Intel-gfx] " Ramalingam C
2019-12-12 19:02 ` [PATCH v2 04/12] drm/i915: Intercept Aksv writes in the aux hooks Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 10:52 ` Ramalingam C
2019-12-13 10:52 ` [Intel-gfx] " Ramalingam C
2019-12-12 19:02 ` [PATCH v2 05/12] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 10:43 ` Ramalingam C
2019-12-13 10:43 ` [Intel-gfx] " Ramalingam C
2019-12-12 19:02 ` [PATCH v2 06/12] drm/i915: Factor out hdcp->value assignments Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 11:11 ` Ramalingam C
2019-12-13 11:11 ` [Intel-gfx] " Ramalingam C
2019-12-12 19:02 ` [PATCH v2 07/12] drm/i915: Protect workers against disappearing connectors Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 11:10 ` Ramalingam C
2019-12-13 11:10 ` [Intel-gfx] " Ramalingam C
2019-12-13 19:04 ` Sean Paul [this message]
2019-12-13 19:04 ` Sean Paul
2019-12-12 19:02 ` [PATCH v2 08/12] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 11:58 ` Ramalingam C
2019-12-13 11:58 ` [Intel-gfx] " Ramalingam C
2019-12-13 19:03 ` Sean Paul
2019-12-13 19:03 ` [Intel-gfx] " Sean Paul
2019-12-12 19:02 ` [PATCH v2 09/12] drm/i915: Support DP MST in enc_to_dig_port() function Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-12 19:02 ` [PATCH v2 10/12] drm/i915: Use ddi_update_pipe in intel_dp_mst Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-12 19:02 ` [PATCH v2 11/12] drm/i915: Expose HDCP shim functions from dp for use by dp_mst Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-13 11:25 ` Ville Syrjälä
2019-12-13 11:25 ` [Intel-gfx] " Ville Syrjälä
2019-12-13 11:59 ` Jani Nikula
2019-12-13 11:59 ` [Intel-gfx] " Jani Nikula
2019-12-12 19:02 ` [PATCH v2 12/12] drm/i915: Add HDCP 1.4 support for MST connectors Sean Paul
2019-12-12 19:02 ` [Intel-gfx] " Sean Paul
2019-12-12 21:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for HDCP 1.4 over MST connectors (rev2) Patchwork
2019-12-12 21:34 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2019-12-12 22:50 ` Sean Paul
2019-12-12 22:55 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191213190441.GF41609@art_vandelay \
--to=sean@poorly.run \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ramalingam.c@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=seanpaul@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.