All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca.ceresoli@bootlin.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Hui Pu <Hui.Pu@gehealthcare.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/7] drm/bridge: lock the encoder bridge chain mutex during insertion
Date: Mon, 29 Sep 2025 16:53:21 +0200	[thread overview]
Message-ID: <20250929165321.28b8bbcd@booty> (raw)
In-Reply-To: <20250929-enigmatic-delicate-mussel-f36b89@houat>

On Mon, 29 Sep 2025 14:46:18 +0200
Maxime Ripard <mripard@kernel.org> wrote:

> On Fri, Sep 26, 2025 at 05:59:44PM +0200, Luca Ceresoli wrote:
> > drm_bridge_attach() modifies the encoder bridge chain, so take a mutex
> > around such operations to allow users of the chain to protect themselves
> > from chain modifications while iterating.
> > 
> > This change does not apply to drm_bridge_detach() because:
> >  * only the drm_encoder.c calls it, not bridge drivers (unlike
> >    drm_bridge_attach())
> >  * the only drm_bridge_detach() caller is drm_encoder_cleanup() which
> >    already locks the mutex for the entire cleanup loop, thus additionally
> >    locking it here would deadlock
> >  * drm_bridge_detach() is recursively calling itself along the chain, so
> >    care would be needed to avoid deadlocks
> > Add a comment to clarify that is intended.
> > 
> > Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> > ---
> >  drivers/gpu/drm/drm_bridge.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 630b5e6594e0affad9ba48791207c7b403da5db8..90e467cf91a134342c80d2f958b928472aaf0d8b 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -453,10 +453,12 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> >  	bridge->dev = encoder->dev;
> >  	bridge->encoder = encoder;
> >  
> > +	drm_encoder_chain_lock(encoder);
> >  	if (previous)
> >  		list_add(&bridge->chain_node, &previous->chain_node);
> >  	else
> >  		list_add(&bridge->chain_node, &encoder->bridge_chain);
> > +	drm_encoder_chain_unlock(encoder);
> >  
> >  	if (bridge->funcs->attach) {
> >  		ret = bridge->funcs->attach(bridge, encoder, flags);
> > @@ -487,7 +489,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> >  err_reset_bridge:
> >  	bridge->dev = NULL;
> >  	bridge->encoder = NULL;
> > +	drm_encoder_chain_lock(encoder);
> >  	list_del(&bridge->chain_node);
> > +	drm_encoder_chain_unlock(encoder);
> >  
> >  	if (ret != -EPROBE_DEFER)
> >  		DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
> > @@ -503,6 +507,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> >  }
> >  EXPORT_SYMBOL(drm_bridge_attach);
> >  
> > +/*
> > + * Invoked by the encoder during encoder cleanup in drm_encoder_cleanup(),
> > + * so should generally *not* be called by driver code.  
> 
> Why not?

Because this is what drm_bridge_attach() says O:-)

> * drm_bridge_attach - attach the bridge to an encoder's chain
...
> * Note that bridges attached to encoders are auto-detached during encoder
> * cleanup in drm_encoder_cleanup(), so drm_bridge_attach() should generally
> * *not* be balanced with a drm_bridge_detach() in driver code.

Also, it's what the code does.

> Also, it looks entirely unrelated to the rest of the patch.

Sure, I can split it. It is also redundant given that's repeating what
drm_bridge_attach() says.

I wrote this comment for future people looking at this code. If
_attach() takes a lock and _detach() does not, it could look like a
potential mistake, and someone could spend precious hours in trying to
fix it.

Maybe replace with:

  /* Must be called with the encoder bridge chain locked */

?

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2025-09-29 14:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-26 15:59 [PATCH 0/7] drm/bridge: protect encoder bridge chain with a mutex Luca Ceresoli
2025-09-26 15:59 ` [PATCH 1/7] drm/encoder: add mutex to protect the bridge chain Luca Ceresoli
2025-09-29 12:43   ` Maxime Ripard
2025-09-29 14:45     ` Luca Ceresoli
2025-09-26 15:59 ` [PATCH 2/7] drm/encoder: drm_encoder_cleanup: take chain mutex while tearing down Luca Ceresoli
2025-09-29 12:45   ` Maxime Ripard
2025-09-29 14:31     ` Luca Ceresoli
2025-10-03 10:37       ` Luca Ceresoli
2025-09-26 15:59 ` [PATCH 3/7] drm/bridge: lock the encoder bridge chain mutex during insertion Luca Ceresoli
2025-09-29 12:46   ` Maxime Ripard
2025-09-29 14:53     ` Luca Ceresoli [this message]
2025-09-26 15:59 ` [PATCH 4/7] drm/bridge: lock the encoder chain in scoped for_each loops Luca Ceresoli
2025-09-30  6:16   ` kernel test robot
2025-10-02 15:33     ` Luca Ceresoli
2025-09-26 15:59 ` [PATCH 5/7] drm/bridge: prevent encoder chain changes while iterating with list_for_each_entry_from() Luca Ceresoli
2025-09-26 15:59 ` [PATCH 6/7] drm/bridge: prevent encoder chain changes while iterating with list_for_each_entry_reverse() Luca Ceresoli
2025-09-26 15:59 ` [PATCH 7/7] drm/bridge: prevent encoder chain changes while iterating in drm_atomic_bridge_chain_post_disable/pre_enable() Luca Ceresoli

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=20250929165321.28b8bbcd@booty \
    --to=luca.ceresoli@bootlin.com \
    --cc=Hui.Pu@gehealthcare.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=rfoss@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=tzimmermann@suse.de \
    /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.