On Fri, Dec 26, 2025 at 07:28:43PM +0100, Michael Nazzareno Trimarchi wrote:
> Hi Tom
> 
> On Fri, Dec 19, 2025 at 9:21 PM Tom Rini <[email protected]> wrote:
> >
> > The devm alloc functions that we have may follow the Linux kernel model
> > where allocations are (almost always) automatically free()'d. However,
> > quite often we don't enable, in full U-Boot, the corresponding automatic
> > free. This in turn leads to memory leaks. Rather than manually tracking
> > allocations and implementing frees, rework things so that we follow
> > expectations now and enable the DEVRES functionality to manage frees.
> >
> > This turns DEVRES from a prompted symbol to a symbol that must be
> > select'd, and we now remove our non-managed alloc/free functions from
> > outside of xPL builds.
[snip]
> > @@ -279,8 +280,8 @@ config DEVRES
> >           released whether initialization fails half-way or the device gets
> >           detached.
> >
> > -         If this option is disabled, devres functions fall back to
> > -         non-managed variants.  For example, devres_alloc() to kzalloc(),
> > +         This option is disabled in xPL phases anddevres functions fall 
> > back
> 
> Fix this typo

OK.

[snip]
> Can you please in the commit message a concrete example on what this
> commit takes care of?
> In short expand here:
> " in full U-Boot, the corresponding automatic free. This in turn leads
> to memory leaks."

Sure. So for example:
commit 00e1fed93c8c3e4c9037741ea1b70a9e693a6e65
Author: Francois Berder <[email protected]>
Date:   Tue Nov 11 11:30:19 2025 +0100

    firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource
    
    - Fix temp memory leak
    - Free memory during error handling
    
    Signed-off-by: Francois Berder <[email protected]>

Is needed (I'd have to re-read the threads to see if in whole or in
part) because DEVRES is optional today. And barring
drivers/core/devres.c doesn't work the way it's documented and expected,
the normal unwind path will eventually say "Ah, and devm_kfree these
devm_kmalloc'd areas". This was part of either the discussion for that
patch, or another one of Francois' patches adding devm_kfree() calls to
devm_kmalloc()'d areas.

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to