Re: Re: [PATCH] firmware: Hold a reference for of_find_compatible_node()

[Greg KH]

On Mon, Jun 27, 2022 at 10:51:38PM +0800, Liang He wrote:
> 
> 
> At 2022-06-27 22:09:43, "Greg KH" <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxx>
> >> ---
> >>  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@xxxxxxx/
> 
> 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