[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250929-flat-koel-from-nibiru-665d49@houat>
Date: Mon, 29 Sep 2025 14:45:10 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Luca Ceresoli <luca.ceresoli@...tlin.com>
Cc: 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>, Hui Pu <Hui.Pu@...ealthcare.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] drm/encoder: drm_encoder_cleanup: take chain mutex
while tearing down
On Fri, Sep 26, 2025 at 05:59:43PM +0200, Luca Ceresoli wrote:
> drm_encoder_cleanup() modifies the encoder chain by removing bridges via
> drm_bridge_detach(). Protect this whole operation by taking the mutex, so
> any users iterating over the chain will not access it during the change.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@...tlin.com>
> ---
> drivers/gpu/drm/drm_encoder.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 3261f142baea30c516499d23dbf8d0acf5952cd6..3a04bedf9b759acd6826864b7f2cc9b861a8f170 100644
> --- 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?
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)
Powered by blists - more mailing lists