linux-kernel - Re: [PATCH 2/8] of: Introduce for_each_*_child_of_node_scoped() to automate of_node

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240212113728.00001e81@Huawei.com>
Date: Mon, 12 Feb 2024 11:37:28 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Julia Lawall <julia.lawall@...ia.fr>
CC: Jonathan Cameron <jic23@...nel.org>, <linux-iio@...r.kernel.org>, "Rob
 Herring" <robh@...nel.org>, Frank Rowand <frowand.list@...il.com>,
	<linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>,
	Nicolas Palix <nicolas.palix@...g.fr>, Sumera Priyadarsini
	<sylphrenadin@...il.com>, "Rafael J . Wysocki" <rafael@...nel.org>, "Len
 Brown" <lenb@...nel.org>, <linux-acpi@...r.kernel.org>, Andy Shevchenko
	<andriy.shevchenko@...ux.intel.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Nuno Sá <nuno.sa@...log.com>
Subject: Re: [PATCH 2/8] of: Introduce for_each_*_child_of_node_scoped() to
 automate of_node_put() handling

On Mon, 12 Feb 2024 09:20:35 +0100 (CET)
Julia Lawall <julia.lawall@...ia.fr> wrote:

> On Sun, 11 Feb 2024, Jonathan Cameron wrote:
> 
> > From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> >
> > To avoid issues with out of order cleanup, or ambiguity about when the
> > auto freed data is first instantiated, do it within the for loop definition.
> >
> > The disadvantage is that the struct device_node *child variable creation
> > is not immediately obvious where this is used.
> > However, in many cases, if there is another definition of
> > struct device_node *child; the compiler / static analysers will notify us
> > that it is unused, or uninitialized.
> >
> > Note that, in the vast majority of cases, the _available_ form should be
> > used and as code is converted to these scoped handers, we should confirm
> > that any cases that do not check for available have a good reason not
> > to.  
> 
> Is it a good idea to make the two changes at once?  Maybe it would slow
> down the use of the scoped form, which can really simplify the code.

Good question.  I combined them based on what I think Rob was asking for.

Rob,

What would you prefer?

Jonathan

> 
> julia
> 
> >
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > ---
> >  include/linux/of.h | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/include/linux/of.h b/include/linux/of.h
> > index 50e882ee91da..024dda54b9c7 100644
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -1430,10 +1430,23 @@ static inline int of_property_read_s32(const struct device_node *np,
> >  #define for_each_child_of_node(parent, child) \
> >  	for (child = of_get_next_child(parent, NULL); child != NULL; \
> >  	     child = of_get_next_child(parent, child))
> > +
> > +#define for_each_child_of_node_scoped(parent, child) \
> > +	for (struct device_node *child __free(device_node) =		\
> > +	     of_get_next_child(parent, NULL);				\
> > +	     child != NULL;						\
> > +	     child = of_get_next_child(parent, child))
> > +
> >  #define for_each_available_child_of_node(parent, child) \
> >  	for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> >  	     child = of_get_next_available_child(parent, child))
> >
> > +#define for_each_available_child_of_node_scoped(parent, child) \
> > +	for (struct device_node *child __free(device_node) =		\
> > +	     of_get_next_available_child(parent, NULL);			\
> > +	     child != NULL;						\
> > +	     child = of_get_next_available_child(parent, child))
> > +
> >  #define for_each_of_cpu_node(cpu) \
> >  	for (cpu = of_get_next_cpu_node(NULL); cpu != NULL; \
> >  	     cpu = of_get_next_cpu_node(cpu))
> > --
> > 2.43.1
> >
> >