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:
>> On 8/4/2026 3:54 PM, Jeff Johnson wrote:
>>> On 11/16/2025 7:56 AM, Ally Heev wrote:
>>>> 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 <[email protected]>
>>>> Reported-by: Dan Carpenter <[email protected]>
>>>> Closes: https://lore.kernel.org/all/[email protected]/
>>>> Signed-off-by: Ally Heev <[email protected]>
>>>>
>>>> [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