linux-kernel - Re: [RFC PATCH 0/5] of: automate of_node_put()

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: <20240201152144.000078d6@Huawei.com>
Date: Thu, 1 Feb 2024 15:21:44 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
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>, 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>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Nuno Sá <nuno.sa@...log.com>
Subject: Re: [RFC PATCH 0/5] of: automate of_node_put() - new approach to
 loops.

> > 3) Introduced the pointer to auto put device_node only within the
> >    for loop scope.
> > 
> > +#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;						\  
> 
> Just
> 
> 	     child;

Agreed that's the same, but was thinking to follow local style.
I don't feel strongly though so fine with dropping the != NULL

> 
> > +	     child = of_get_next_available_child(parent, child))
> > +
> > 
> > This series is presenting option 3.  I only implemented this loop out of
> > all the similar ones and it is only compile tested.
> > 
> > Disadvantage Rob raised is that it isn't obvious this macro will instantiate
> > a struct device_node *child.  I can't see a way around that other than option 2
> > above, but all suggestions welcome.  Note that if a conversion leaves an
> > 'external' struct device_node *child variable, in many cases the compiler
> > will catch that as an unused variable. We don't currently run shaddow
> > variable detection in normal kernel builds, but that could also be used
> > to catch such bugs.  
>