linux-kernel - Re: [PATCH] sysrq: Auto release device node using _

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: Fri, 12 Apr 2024 08:21:30 +0200 (CEST)
From: Julia Lawall <julia.lawall@...ia.fr>
To: Greg KH <gregkh@...uxfoundation.org>, Rob Herring <robh@...nel.org>, 
    Saravana Kannan <saravanak@...gle.com>, devicetree@...r.kernel.org
cc: Roman Storozhenko <romeusmeister@...il.com>, jirislaby@...nel.org, 
    skhan@...uxfoundation.org, javier.carrasco.cruz@...il.com, 
    linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH] sysrq: Auto release device node using __free attribute

[Adding the OF maintainers and device tree mailing list]

> > Maybe it would be nice to get rid of of_node_puts in the general case?
>
> That's a call for the of maintainer to make, and then if so, to do it
> across the whole tree, right?

Sure.

Rob and Saravana, what do you think about the following:

* Is it ok to use __free(device_tree) directly in a declaration, or is
there some macro that should be used instead?

* If is ok to use __free(device_tree) even in simple cases where a
variable is just declared at the start of the scope and freed at the end,
and there is no internediate error handling code?

Please see for example:

https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2401291455430.8649@hadrien/

But I don't think we can do the whole thing at once, in one patch.  There
are a lot of things that need to be checked, and it don't break anything
to do them one at a time.

>
> > Even though this one is not very annoying, there are some other functions
> > where there are many of_node_puts, and convoluted error handling code to
> > incorporate them on both the success and failure path.  So maybe it would
> > be better to avoid the situation of having them sometimes and not having
> > them other times?  But this is an opinion, and if the general consensus is
> > to only get rid of the cases that currently add complexity, then that is
> > possible too.
>
> Let's keep things simple until it has to be complex please.

I meant that the current code is complex and error prone, and using __free
eliminates code that is ugly and has led to memory leaks in the past (and
a lot of effort to find and fix them in the past).  Even if some instances
don't have that property, they may become more complex in the future, if
some error condition is detected.

julia