On Tue, Aug 29, 2017 at 08:45:32PM +0200, Alexander Graf wrote:
> On 08/29/2017 08:25 PM, Leif Lindholm wrote:
> > On Tue, Aug 29, 2017 at 06:00:35PM +0200, Alexander Graf wrote:
> > > When we exit grub, we don't free all the memory that we allocated earlier
> > > for our heap region. This can cause problems with setups where you try
> > > to descend the boot order using "exit" entries, such as PXE -> HD boot
> > > scenarios.
> > >
> > > Signed-off-by: Alexander Graf <[email protected]>
> > Really happy to see this, but repeating a comment here from irc:
> > This deals with the biggest problem with returning to UEFI - GRUB
> > allocates 25% of available RAM, which before this patch we don't
> > release. However, various operations may allocate EFI memory directly,
> > and those allocations are not currently being tracked.
> >
> > If further allocations could be tracked from
> > grub_efi_allocate_pages_real, these could be unwound in
> > _memory_fini(). Those can safely be allocated from the heap.
>
> I'm using pool allocations now which *usually* go into a malloc like pool on
> the UEFI side anyway, hence I don't think we should complicate the logic
> even more and differentiate between heap and non-heap allocations. I'll just
> add all allocations from efi_allocate_pages_real() to the list and free them
> on exit - that should be safest.
Sure, the comment was intended to point out a relaxation of
requirements, not a restriction. I.e. unlike the entries for
tracking the allocations of the heap, later allocations _can_ be
stored on the heap.
/
Leif
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
