[PATCH] bootstd: Avoid freeing a non-allocated buffer

[Simon Glass]

Hi Heinrich,

On Wed, 15 Nov 2023 at 19:18, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 11/16/23 02:35, Simon Glass wrote:
> > EFI applications can be very large and thus used to cause boot failures
> > when malloc() space was exhausted.
> >
> > A recent changed fixed this by using the kernel_addr_r environment var
> > as the address of the buffer. However, it still frees the buffer when
> > the bootflow is discarded.
> >
> > Fix this by introducing a flag to indicate whether the buffer was
> > allocated, or not.
> >
> > Note that kernel_addr_r is not the last word here. It might be better
> > to use lmb to place images. But there is a lot of refactoring to do
>
> We need a discussion about memory management. We currently have:
>
> * malloc
> * EFI - AllocatePages(), AllocatePool()
> * lmb
> * preassigned addresses like $kernel_addr_r, $fdt_addr_r

Yes indeed. There have been discussions already, but we need to do
this on the ML.

>
> EFI manages memory on page level. It needs to provide a complete memory
> map to the OS with flags for different types of memory. Currently it is
> not aware of where files are loaded and might allocate those regions for
> its own usage.
>
> lmb does not track any allocations but tries to recreate a memory map on
> the fly whenever a file is loaded.
>
> It would be preferable to allocate memory for files and require to
> explicitly unload a file before reusing the same memory area.
>
> We should start a separate thread on this topic.

Indeed. If you start it, I will reply with some thoughts.

The nice thing is that with bootstd we can start to tidy all this up
and make sure it has tests.

>
> > before we can remove the environment variables. The distro scripts rely
> > on them so it is safe for bootstd to do so too.
> >
> > Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > Reported by: Simon Glass <sjg at chromium.org>
> > Reported by: Shantur Rathore <i at shantur.com>
>
> Reviewed-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>

[..]

Regards,
Simon