Re: __free usage

On 8/5/2026 4:56 AM, Przemek Kitszel wrote:

On 8/5/26 00:56, Jeff Johnson via Intel-wired-lan wrote:

quoted

On 8/4/2026 3:54 PM, Jeff Johnson wrote:

quoted

On 11/16/2025 7:56 AM, Ally Heev wrote:

quoted

usage of cleanup attributes is discouraged in net [1], achieve cleanup
using goto. In this patch though, only uninitialized pointers with __free
attribute are cleaned as they can cause undefined behavior when they
go out of scope

Suggested-by: Simon Horman <horms@kernel.org>
Reported-by: Dan Carpenter <redacted>
Closes: https://lore.kernel.org/all/aPiG_F5EBQUjZqsl@stanley.mountain/ (local)
Signed-off-by: Ally Heev <redacted>

[1] https://docs.kernel.org/process/maintainer-netdev.html#using-device-managed-and-cleanup-h-constructs

<SMH>

If using __free() *correctly* gives more readable code, why wouldn't we do it?

The only problem with this function is that it doesn't follow the guidance
from cleanup.h:

  * the recommendation is to always define and assign variables in one
  * statement and not group variable definitions at the top of the
  * function when __free() is used.

OMG, not sure why Thunderbird showed this as a recent unread e-mail.
Please ignore this noise!

always happy to see some __free() advocates :)

perhaps with our new meticulous friend Sashiko __free() would not be
misused anymore, especially if we let them know the following quote:

 > So just make the rule be that __free() without an assignment is 
simply > a bug.
 >               Linus

and the resulting "less code" is always better (if only to fit more
data into the AI context window)

There are unfortunately some uses of __free() that require a NULL assignment,
namely when the allocation is passed back via  a ** argument -- see
__free(firmware). But for all the rest it would be good to have the
consistency. Anything to help reduce often buggy cleanup gotos.

/jeff