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]
Date:   Mon, 27 Jun 2022 17:03:59 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Liang He <windhl@....com>
Cc:     broonie@...nel.org, ckeepax@...nsource.cirrus.com,
        michal.simek@...inx.com, abhyuday.godhasara@...inx.com,
        simont@...nsource.cirrus.com, ronak.jain@...inx.com,
        peng.fan@....com, linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] firmware: Hold a reference for
 of_find_compatible_node()

On Mon, Jun 27, 2022 at 10:51:38PM +0800, Liang He wrote:
> 
> 
> At 2022-06-27 22:09:43, "Greg KH" <gregkh@...uxfoundation.org> wrote:
> >On Tue, Jun 21, 2022 at 11:26:25AM +0800, Liang He wrote:
> >> In of_register_trusted_foundations(), we need to hold the reference
> >> returned by of_find_compatible_node() and then use it to call
> >> of_node_put() for refcount balance.
> >> 
> >> Signed-off-by: Liang He <windhl@....com>
> >> ---
> >>  include/linux/firmware/trusted_foundations.h | 8 ++++++--
> >>  1 file changed, 6 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/include/linux/firmware/trusted_foundations.h b/include/linux/firmware/trusted_foundations.h
> >> index be5984bda592..399471c2f1c7 100644
> >> --- a/include/linux/firmware/trusted_foundations.h
> >> +++ b/include/linux/firmware/trusted_foundations.h
> >> @@ -71,12 +71,16 @@ static inline void register_trusted_foundations(
> >>  
> >>  static inline void of_register_trusted_foundations(void)
> >>  {
> >> +	struct device_node *np = of_find_compatible_node(NULL, NULL, "tlm,trusted-foundations");
> >> +
> >> +	of_node_put(np);
> >> +	if (!np)
> >
> >While this is technically correct, you are now checking to see if this
> >points to a memory location that you no longer know what it really
> >belongs to.  C will let you do this, but it might be nicer to fix it up
> >properly so it doesn't look like this.
> >
> >thanks,
> >
> >greg k-h
> 
> Hi,Greg KH,
> 
> Thanks very much for your effort to review my patch.
> 
> In fact, I have reported a commit for this kind of 'check-after-put' coding style:
> https://lore.kernel.org/all/20220617112636.4041671-1-windhl@126.com/
> 
> But I have been told to keep such style and I think the explanation is also reasonable.

It's not very reasonable if you talk to C compiler authors.  They can do
crazy things with dereferenced memory locations, including optimizing
them away entirely as they now "know" that this does not point to any
valid memory so it's an undefined thing that the compiler is being asked
to do.

> So when I make this patch, I am indeed confused what I should write.
> 
> Finally, I think it is better to be consistent with current coding style so
> I chose this 'check-after-put' style.
> 
> But if you think it is better to use a normal order, i.e., check-then-put,
> I am, of cause, very happy to send a new patch for this bug and I will
> also keep to use this coding style in future.

check and then put please.  That prevents you from having to fix up this
type of thing in a few years when the compilers all start to blow up on
it.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ