[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/2] efi: Free malloc regions on exit

From: Leif Lindholm
Subject: Re: [PATCH v3 2/2] efi: Free malloc regions on exit
Date: Tue, 29 Aug 2017 20:05:06 +0100
User-agent: NeoMutt/20170113 (1.7.2)

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 <address@hidden>
> > 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]