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 2/7] drm/encoder: drm_encoder_cleanup: take chain mutex while tearing down
Date: Fri, 3 Oct 2025 12:37:26 +0200 [thread overview]
Message-ID: <20251003123726.4bf38c76@booty> (raw)
In-Reply-To: <20250929163127.5ad20e05@booty>
Hello,
On Mon, 29 Sep 2025 16:31:27 +0200
Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
> > > --- a/drivers/gpu/drm/drm_encoder.c
> > > +++ b/drivers/gpu/drm/drm_encoder.c
> > > @@ -195,9 +195,11 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> > > * the indices on the drm_encoder after us in the encoder_list.
> > > */
> > >
> > > + mutex_lock(&encoder->bridge_chain_mutex);
> > > list_for_each_entry_safe(bridge, next, &encoder->bridge_chain,
> > > chain_node)
> > > drm_bridge_detach(bridge);
> > > + mutex_unlock(&encoder->bridge_chain_mutex);
> >
> > You were claiming that the mutex was to prevent issues with concurrent
> > iteration and removal of the list members. list_for_each_entry_safe() is
> > explicitly made to protect against that. Why do we need both?
>
> You're right saying we don't need both. With a mutex preventing the list
> from any change, we can actually simpify code a bit to use the non-safe
> list macro:
>
> - struct drm_bridge *bridge, *next;
> + struct drm_bridge *bridge;
> ...
> + mutex_lock(&encoder->bridge_chain_mutex);
> - list_for_each_entry_safe(bridge, next, &encoder->bridge_chain,
> + list_for_each_entry(bridge, &encoder->bridge_chain,
> chain_node)
> drm_bridge_detach(bridge);
> + mutex_unlock(&encoder->bridge_chain_mutex);
After looking at it better I realized the _safe variant here is still
needed as the current loop entry is removed inside the loop. The
non-safe version, at the end of the first iteration, would look for the
next element in the now-removed list_head, thus being derailed.
v2 on its way with this taken into account along with the other
discussed items.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2025-10-03 10:37 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 [this message]
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
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=20251003123726.4bf38c76@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.