[PATCH 3/6] efi: Allow monitoring of page allocations
Simon Glass
sjg at chromium.org
Fri Jul 26 01:33:00 CEST 2024
Hi Heinrich,
On Thu, 25 Jul 2024 at 10:26, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 25.07.24 15:56, Simon Glass wrote:
> > Some confusion has set in over which memory-allocation method to use in
> > EFI-related code, particularly for the pool allocator. Most of the time,
> > malloc() is used, which is correct.
> >
> > However in some cases the page allocator is used. This means that some
> > EFI information is sitting 'in space', outside of the malloc() and not
> > allocated by lmb. This can cause problems if an image happens to be
> > loaded at the same address.
>
> We already agreed to resolve this problem by integrating LMB and UEFI
> memory allocation.
>
> Please, contribute to reviewing
> [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
> https://lists.denx.de/pipermail/u-boot/2024-July/557962.html
Yes, I reviewed the RFC some time ago and actually referenced that
series in the cover letter. This series is aimed at something
different, though. Please see the cover letter.
>
> >
> > From what I can tell, there is currently no checking of this, but it
> > seems to be a real bug.
> >
> > Add a way to control whether allocations are permitted, to help debug
> > these sorts of issues.
>
> Calling AllocatePages() and AllocatedPool() cannot be forbidden as we
> want to comply to the UEFI specification.
Right. My point is this for debugging only, to allow allocations to be
forbidden when they should not be done, thus allowing us to sort out
the problems. Once there are no more problems, this patch can be
reverted, but that might take some years.
[..]
Regards,
Simon
More information about the U-Boot
mailing list