From: Sean Paul <sean@poorly.run> To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Cc: daniel.vetter@ffwll.ch, seanpaul@chromium.org, juston.li@intel.com, rodrigo.vivi@intel.com Subject: [PATCH v6 07/16] drm/i915: Protect workers against disappearing connectors Date: Wed, 29 Apr 2020 15:54:53 -0400 [thread overview] Message-ID: <20200429195502.39919-8-sean@poorly.run> (raw) In-Reply-To: <20200429195502.39919-1-sean@poorly.run> 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. Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run #v5 Changes in v2: -Added to the set Changes in v3: -Change the WARN_ON condition in intel_hdcp_cleanup to allow for initializing connectors as well Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None --- drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ++++++++++++++++++++--- 1 file changed, 39 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index ec02eaa43d39..a4446d47ef27 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -888,8 +888,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 */ @@ -981,6 +983,8 @@ static void intel_hdcp_prop_work(struct work_struct *work) mutex_unlock(&hdcp->mutex); drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex); + + drm_connector_put(&connector->base); } bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port) @@ -1860,6 +1864,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); @@ -2175,12 +2182,39 @@ 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); + /* + * If the connector is registered, it's possible userspace could kick + * off another HDCP enable, which would re-spawn the workers. + */ + drm_WARN_ON(connector->base.dev, + connector->base.registration_state == DRM_CONNECTOR_REGISTERED); + + /* + * Now that the connector is not registered, 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). + */ + drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work)); + + mutex_lock(&hdcp->mutex); + kfree(hdcp->port_data.streams); + hdcp->shim = NULL; + mutex_unlock(&hdcp->mutex); } void intel_hdcp_atomic_check(struct drm_connector *connector, -- 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: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Cc: daniel.vetter@ffwll.ch, seanpaul@chromium.org Subject: [Intel-gfx] [PATCH v6 07/16] drm/i915: Protect workers against disappearing connectors Date: Wed, 29 Apr 2020 15:54:53 -0400 [thread overview] Message-ID: <20200429195502.39919-8-sean@poorly.run> (raw) In-Reply-To: <20200429195502.39919-1-sean@poorly.run> 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. Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run #v5 Changes in v2: -Added to the set Changes in v3: -Change the WARN_ON condition in intel_hdcp_cleanup to allow for initializing connectors as well Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None --- drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ++++++++++++++++++++--- 1 file changed, 39 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index ec02eaa43d39..a4446d47ef27 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -888,8 +888,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 */ @@ -981,6 +983,8 @@ static void intel_hdcp_prop_work(struct work_struct *work) mutex_unlock(&hdcp->mutex); drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex); + + drm_connector_put(&connector->base); } bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port) @@ -1860,6 +1864,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); @@ -2175,12 +2182,39 @@ 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); + /* + * If the connector is registered, it's possible userspace could kick + * off another HDCP enable, which would re-spawn the workers. + */ + drm_WARN_ON(connector->base.dev, + connector->base.registration_state == DRM_CONNECTOR_REGISTERED); + + /* + * Now that the connector is not registered, 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). + */ + drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work)); + + mutex_lock(&hdcp->mutex); + kfree(hdcp->port_data.streams); + hdcp->shim = NULL; + mutex_unlock(&hdcp->mutex); } void intel_hdcp_atomic_check(struct drm_connector *connector, -- 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:[~2020-04-29 19:55 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-29 19:54 [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 01/16] drm/i915: Fix sha_text population code Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` Sean Paul 2020-05-01 2:55 ` Sasha Levin 2020-05-01 2:55 ` [Intel-gfx] " Sasha Levin 2020-05-06 14:00 ` Ramalingam C 2020-05-06 14:00 ` [Intel-gfx] " Ramalingam C 2020-05-06 14:00 ` Ramalingam C 2020-04-29 19:54 ` [PATCH v6 02/16] drm/i915: Clear the repeater bit on HDCP disable Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` Sean Paul 2020-05-01 2:55 ` Sasha Levin 2020-05-01 2:55 ` [Intel-gfx] " Sasha Levin 2020-05-01 2:55 ` Sasha Levin 2020-05-06 14:02 ` Ramalingam C 2020-05-06 14:02 ` [Intel-gfx] " Ramalingam C 2020-05-06 14:02 ` Ramalingam C 2020-04-29 19:54 ` [PATCH v6 03/16] drm/i915: WARN if HDCP signalling is enabled upon disable Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-05-06 14:18 ` Ramalingam C 2020-05-06 14:18 ` [Intel-gfx] " Ramalingam C 2020-04-29 19:54 ` [PATCH v6 04/16] drm/i915: Intercept Aksv writes in the aux hooks Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-05-06 14:13 ` Ramalingam C 2020-05-06 14:13 ` [Intel-gfx] " Ramalingam C 2020-04-29 19:54 ` [PATCH v6 05/16] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 06/16] drm/i915: Factor out hdcp->value assignments Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` Sean Paul [this message] 2020-04-29 19:54 ` [Intel-gfx] [PATCH v6 07/16] drm/i915: Protect workers against disappearing connectors Sean Paul 2020-04-29 19:54 ` [PATCH v6 08/16] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-05-15 12:39 ` Ramalingam C 2020-05-15 12:39 ` [Intel-gfx] " Ramalingam C 2020-04-29 19:54 ` [PATCH v6 09/16] drm/i915: Support DP MST in enc_to_dig_port() function Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 10/16] drm/i915: Use ddi_update_pipe in intel_dp_mst Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 11/16] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 12/16] drm/i915: Plumb port through hdcp init Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:54 ` [PATCH v6 13/16] drm/i915: Add connector to hdcp_shim->check_link() Sean Paul 2020-04-29 19:54 ` [Intel-gfx] " Sean Paul 2020-04-29 19:55 ` [PATCH v6 14/16] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message Sean Paul 2020-04-29 19:55 ` [Intel-gfx] " Sean Paul 2020-04-29 19:55 ` [PATCH v6 15/16] drm/i915: Print HDCP version info for all connectors Sean Paul 2020-04-29 19:55 ` [Intel-gfx] " Sean Paul 2020-04-29 19:55 ` [PATCH v6 16/16] drm/i915: Add HDCP 1.4 support for MST connectors Sean Paul 2020-04-29 19:55 ` [Intel-gfx] " Sean Paul 2020-05-15 14:42 ` Ramalingam C 2020-05-15 14:42 ` [Intel-gfx] " Ramalingam C 2020-06-18 18:20 ` Sean Paul 2020-06-18 18:20 ` [Intel-gfx] " Sean Paul 2020-04-29 20:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add support for HDCP 1.4 over MST connectors (rev6) Patchwork 2020-04-29 21:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2020-04-30 5:48 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork 2020-05-15 14:48 ` [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors Ramalingam C 2020-05-15 14:48 ` [Intel-gfx] " Ramalingam C 2020-05-18 14:32 ` Sean Paul 2020-05-18 14:32 ` [Intel-gfx] " Sean Paul 2020-05-18 16:41 ` Ramalingam C 2020-05-18 16:41 ` [Intel-gfx] " Ramalingam C 2020-05-20 13:11 ` Sean Paul 2020-05-20 13:11 ` [Intel-gfx] " Sean Paul 2020-05-26 10:38 ` Ramalingam C 2020-05-26 10:38 ` [Intel-gfx] " Ramalingam C
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=20200429195502.39919-8-sean@poorly.run \ --to=sean@poorly.run \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=juston.li@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: linkBe 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.