| 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
| ||
|
Message-ID: <Z8nCJACBmcUNvQB8@phenom.ffwll.local>
Date: Thu, 6 Mar 2025 16:41:24 +0100
From: Simona Vetter <simona.vetter@...ll.ch>
To: Maxime Ripard <mripard@...nel.org>
Cc: Andy Yan <andyshrk@....com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Douglas Anderson <dianders@...omium.org>,
Herve Codina <herve.codina@...tlin.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Simona Vetter <simona.vetter@...ll.ch>
Subject: Re: [PATCH v5 04/16] drm/atomic: Introduce helper to lookup
connector by encoder
On Thu, Mar 06, 2025 at 08:10:16AM +0100, Maxime Ripard wrote:
> On Thu, Mar 06, 2025 at 09:16:24AM +0800, Andy Yan wrote:
> >
> > Hi Maxime and Dmitry:
> >
> > At 2025-03-06 04:13:53, "Dmitry Baryshkov" <dmitry.baryshkov@...aro.org> wrote:
> > >On Wed, Mar 05, 2025 at 02:19:36PM +0100, Maxime Ripard wrote:
> > >> Hi Andy,
> > >>
> > >> On Wed, Mar 05, 2025 at 07:55:19PM +0800, Andy Yan wrote:
> > >> > At 2025-03-04 19:10:47, "Maxime Ripard" <mripard@...nel.org> wrote:
> > >> > >With the bridges switching over to drm_bridge_connector, the direct
> > >> > >association between a bridge driver and its connector was lost.
> > >> > >
> > >> > >This is mitigated for atomic bridge drivers by the fact you can access
> > >> > >the encoder, and then call drm_atomic_get_old_connector_for_encoder() or
> > >> > >drm_atomic_get_new_connector_for_encoder() with drm_atomic_state.
> > >> > >
> > >> > >This was also made easier by providing drm_atomic_state directly to all
> > >> > >atomic hooks bridges can implement.
> > >> > >
> > >> > >However, bridge drivers don't have a way to access drm_atomic_state
> > >> > >outside of the modeset path, like from the hotplug interrupt path or any
> > >> > >interrupt handler.
> > >> > >
> > >> > >Let's introduce a function to retrieve the connector currently assigned
> > >> > >to an encoder, without using drm_atomic_state, to make these drivers'
> > >> > >life easier.
> > >> > >
> > >> > >Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > >> > >Co-developed-by: Simona Vetter <simona.vetter@...ll.ch>
> > >> > >Signed-off-by: Maxime Ripard <mripard@...nel.org>
> > >> > >---
> > >> > > drivers/gpu/drm/drm_atomic.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
> > >> > > include/drm/drm_atomic.h | 3 +++
> > >> > > 2 files changed, 48 insertions(+)
> > >> > >
> > >> > >diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > >> > >index 9ea2611770f43ce7ccba410406d5f2c528aab022..b926b132590e78f8d41d48eb4da4bccf170ee236 100644
> > >> > >--- a/drivers/gpu/drm/drm_atomic.c
> > >> > >+++ b/drivers/gpu/drm/drm_atomic.c
> > >> > >@@ -985,10 +985,55 @@ drm_atomic_get_new_connector_for_encoder(const struct drm_atomic_state *state,
> > >> > >
> > >> > > return NULL;
> > >> > > }
> > >> > > EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
> > >> > >
> > >> > >+/**
> > >> > >+ * drm_atomic_get_connector_for_encoder - Get connector currently assigned to an encoder
> > >> > >+ * @encoder: The encoder to find the connector of
> > >> > >+ * @ctx: Modeset locking context
> > >> > >+ *
> > >> > >+ * This function finds and returns the connector currently assigned to
> > >> > >+ * an @encoder.
> > >> > >+ *
> > >> > >+ * Returns:
> > >> > >+ * The connector connected to @encoder, or an error pointer otherwise.
> > >> > >+ * When the error is EDEADLK, a deadlock has been detected and the
> > >> > >+ * sequence must be restarted.
> > >> > >+ */
> > >> > >+struct drm_connector *
> > >> > >+drm_atomic_get_connector_for_encoder(const struct drm_encoder *encoder,
> > >> > >+ struct drm_modeset_acquire_ctx *ctx)
> > >> > >+{
> > >> > >+ struct drm_connector_list_iter conn_iter;
> > >> > >+ struct drm_connector *out_connector = ERR_PTR(-EINVAL);
> > >> > >+ struct drm_connector *connector;
> > >> > >+ struct drm_device *dev = encoder->dev;
> > >> > >+ int ret;
> > >> > >+
> > >> > >+ ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> > >> > >+ if (ret)
> > >> > >+ return ERR_PTR(ret);
> > >> >
> > >> > It seems that this will cause a deadlock when called from a hotplug
> > >> > handling path, I have a WIP DP diver[0], which suggested by Dmitry to
> > >> > use this API from a &drm_bridge_funcs.detect callback to get the
> > >> > connector, as detect is called by drm_helper_probe_detect, which will
> > >> > hold connection_mutex first, so the deaklock happens:
> > >> >
> > >> > drm_helper_probe_detect(struct drm_connector *connector,
> > >> > struct drm_modeset_acquire_ctx *ctx,
> > >> > bool force)
> > >> > {
> > >> > const struct drm_connector_helper_funcs *funcs = connector->helper_private;
> > >> > struct drm_device *dev = connector->dev;
> > >> > int ret;
> > >> >
> > >> > if (!ctx)
> > >> > return drm_helper_probe_detect_ctx(connector, force);
> > >> >
> > >> > ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
> > >> > if (ret)
> > >> > return ret;
> > >> >
> > >> > if (funcs->detect_ctx)
> > >> > ret = funcs->detect_ctx(connector, ctx, force);
> > >> > else if (connector->funcs->detect)
> > >> > ret = connector->funcs->detect(connector, force);
> > >> > else
> > >> > ret = connector_status_connected;
> > >> >
> > >> > if (ret != connector->status)
> > >> > connector->epoch_counter += 1;
> > >> >
> > >> > So I wonder can we let drm_bridge_funcs.detect pass a connector for
> > >> > this case ?
> > >>
> > >> Do you actually see a deadlock occurring? AFAIK, drm_modeset_lock is
> > >> fine with reentrancy from the same context, so it should work just fine.
> > >
> > >Andy, that probably means that you should use .detect_ctx() and pass the
> > >context to drm_atomic_get_connector_for_encoder().
> >
> > Unfortunately, the drm_bridge_funcs does not have a .detect_ctx() version .
> > The call chain is:
> > drm_helper_probe_detect
> > --> drm_bridge_connector_detect(struct drm_connector *connector, bool force)
> > --> drm_bridge_funcs.detect(bridge)
> > The ctx got dropped when drm_helper_probe_detect call drm_bridge_connector_detect
> > The connector got dropped when connector call it's bridege.detect
> >
> > So I think the simplest solution is to have drm_bridge_funcs.detect
> > directly pass the connector
>
> I don't disagree on principle, but I think a better first step would be
> to provide a detect_ctx hook to bridges.
Yup. There's other reasons you really want to get at the locking context
in detect callbacks, doing this special case by passing something for
everyone doesn't sound like the right approach to me.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Powered by blists - more mailing lists