> > Although majority of the changes are made to
> > drivers/firmware/efi/memmap.c file (which is common across
> > architectures), this bug is only limited to x86_64 machines and hence this
> > patch
> set shouldn't effect any other architectures.
>
> I will give this a test run on the arm64
> Since we're being pedantic, it also makes sense to decide now whether 'area'
> refers to all [discontiguous] regions or just one of them. I'd say the
> former, and
> use 'region' for the latter, i.e., an area may be made up of several regions,
> but
> only one exists of each type.
>
> >
* Ard Biesheuvel wrote:
> So if we are going to rename these things wholesale (which is fine
> with me), I'd prefer it if we can drop the 'map' entirely.
>
> EFI memory table
> EFI memory table entry
> EFI memory table descriptor
So if you don't actively hate the idea (which you don't seem
Hi Sai,
Thanks for Cc'ing me on this patchset.
On 12/05/2018 06:03 AM, Sai Praneeth Prakhya wrote:
Presently, in EFI subsystem of kernel, every time kernel allocates memory for a
new EFI memory map, it forgets to free the memory occupied by old EFI memory
map.
It does clear the mappings
On Wed, 5 Dec 2018 at 08:41, Ingo Molnar wrote:
>
>
> * Sai Praneeth Prakhya wrote:
>
> > Presently, in EFI subsystem of kernel, every time kernel allocates memory
> > for a
> > new EFI memory map, it forgets to free the memory occupied by old EFI
> > memory map.
> > It does clear the mappings
* Sai Praneeth Prakhya wrote:
> Presently, in EFI subsystem of kernel, every time kernel allocates memory for
> a
> new EFI memory map, it forgets to free the memory occupied by old EFI memory
> map.
> It does clear the mappings though (using efi_memmap_unmap()), but forgets to
> free up the
Presently, in EFI subsystem of kernel, every time kernel allocates memory for a
new EFI memory map, it forgets to free the memory occupied by old EFI memory
map.
It does clear the mappings though (using efi_memmap_unmap()), but forgets to
free up the memory. Also, there is another minor issue,
