linux-kernel - Re: [PATCH v2 3/9] drm/bridge: add drm_for_each_bridge_in_chain

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250902235326.678947cd@booty>
Date: Tue, 2 Sep 2025 23:53:26 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Maxime Ripard <mripard@...nel.org>
Cc: 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>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter
 <simona@...ll.ch>, Miguel Ojeda <ojeda@...nel.org>, Nathan Chancellor
 <nathan@...nel.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
 Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Dmitry Baryshkov
 <dmitry.baryshkov@....qualcomm.com>, Chaoyi Chen
 <chaoyi.chen@...k-chips.com>, Hui Pu <Hui.Pu@...ealthcare.com>, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v2 3/9] drm/bridge: add
 drm_for_each_bridge_in_chain_scoped()

Hi Maxime,

On Wed, 20 Aug 2025 11:40:30 +0200
Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:

> Hi Maxime,
> 
> On Tue, 19 Aug 2025 18:01:37 +0200
> Luca Ceresoli <luca.ceresoli@...tlin.com> wrote:
> 
> > Hi Maxime,
> > 
> > On Tue, 19 Aug 2025 15:47:06 +0200
> > Maxime Ripard <mripard@...nel.org> wrote:
> >   
> > > > +/**
> > > > + * drm_for_each_bridge_in_chain_scoped - iterate over all bridges attached
> > > > + *                                       to an encoder
> > > > + * @encoder: the encoder to iterate bridges on
> > > > + * @bridge: a bridge pointer updated to point to the current bridge at each
> > > > + *	    iteration
> > > > + *
> > > > + * Iterate over all bridges present in the bridge chain attached to @encoder.
> > > > + *
> > > > + * Automatically gets/puts the bridge reference while iterating, and puts
> > > > + * the reference even if returning or breaking in the middle of the loop.
> > > > + */
> > > > +#define drm_for_each_bridge_in_chain_scoped(encoder, bridge)		\
> > > > +	for (struct drm_bridge *bridge __free(drm_bridge_put) =		\
> > > > +	     drm_bridge_chain_get_first_bridge(encoder);		\      
> > > 
> > > So my understanding is that the initial value of bridge would be cleaned
> > > up with drm_bridge_put...
> > >     
> > > > +	     bridge;							\
> > > > +	     bridge = drm_bridge_get_next_bridge_and_put(bridge))      
> > > 
> > > ... but also when iterating?
> > > 
> > > So if we have more than 0 values, we put two references?    
> > 
> > No, this is not the case. The __free action is executed only when
> > exiting the entire for loop, not a single iteration.
> > 
> > This is consistent with the fact that the loop variable is persistent
> > across iterations.  
> 
> PS: here's the C language spec reference:
> 
> > 6.8.5.3 The for statement
> > The statement
> > for ( clause-1 ; expression-2 ; expression-3 ) statement
> > behaves as follows:
> > [...]
> > If clause-1 is a declaration, the scope of any identifiers it declares
> > is the remainder of the declaration and the entire loop   
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> https://rgambord.github.io/c99-doc/sections/6/8/5/3/index.html

I think my replies have proven the correctness of the bridge cleanup in
this patch. Based on my arguments, do you agree this patch is correct?

If it is, I think most of the remainder of this series is trivial to
review, and it would be a good step forward for dynamic bridge lifetime
implementation.

Otherwise, don't hesitate to let me know your concerns.

Best regards,
Luca

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