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: <20240204203418.00464af4@jic23-huawei>
Date: Sun, 4 Feb 2024 20:52:20 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: linux-iio@...r.kernel.org, Rob Herring <robh@...nel.org>, Frank Rowand
 <frowand.list@...il.com>, linux-kernel@...r.kernel.org, Julia Lawall
 <Julia.Lawall@...ia.fr>, 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>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [RFC PATCH 2/5] of: Introduce for_each_child_of_node_scoped()
 to automate of_node_put() handling

On Sun, 4 Feb 2024 19:56:11 +0000
Jonathan Cameron <jic23@...nel.org> wrote:

> On Sun, 28 Jan 2024 15:11:01 -0600
> David Lechner <dlechner@...libre.com> wrote:
> 
> > On Sun, Jan 28, 2024 at 10:06 AM Jonathan Cameron <jic23@...nelorg> 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.
> > >
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> > > ---
> > >  include/linux/of.h | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/include/linux/of.h b/include/linux/of.h
> > > index 50e882ee91da..f822226eac6d 100644
> > > --- a/include/linux/of.h
> > > +++ b/include/linux/of.h
> > > @@ -1434,6 +1434,12 @@ static inline int of_property_read_s32(const struct device_node *np,
> > >         for (child = of_get_next_available_child(parent, NULL); child != NULL; \
> > >              child = of_get_next_available_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_available_child(parent, child))    
> > 
> > Doesn't this need to match the initializer (of_get_next_child)?
> > Otherwise it seems like the first node could be a disabled node but no
> > other disabled nodes would be included in the iteration.  
> 
> FwIW that was was entirely unintentional.  Not sure how it happened :(
> Anyhow, now will be for_each_available_child_of_node_scoped() with the
> right first call.

*sigh* Which I can't use for the unittest case (tests fail as a result
as some nodes that need to be covered are not available) so both will need to exist
though we can hopefully review each change for whether the appropriate one
is used afterwards (ignoring whether it was with the non scoped versions)

Jonathan

> 
> > 
> > It seems like we would want two macros, one for each variation,
> > analogous to for_each_child_of_node() and
> > for_each_available_child_of_node().
> > 
> >   
> > > +
> > >  #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.0
> > >
> > >    
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ