audk/MdeModulePkg/Core/Dxe/Mem
Ard Biesheuvel 3f2ae009ec MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries
When attempting to perform page allocations using AllocateAddress, we
fail to check whether the entire region is free before splitting the
region. This may lead to memory being leaked further into the routine,
when it turns out that one of the memory map entries intersected by the
region is already occupied. In this case, prior conversions are not rolled
back.

For instance, starting from this situation

0x000040000000-0x00004007ffff [ConventionalMemory ]
0x000040080000-0x00004009ffff [Boot Data          ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]

a failed EfiLoaderData allocation @ 0x40000000 that covers the BootData
region will fail, but leave the first part of the allocation converted,
so we end up with

0x000040000000-0x00004007ffff [Loader Data        ]
0x000040080000-0x00004009ffff [Boot Data          ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]

even though the AllocatePages() call returned an error.

So let's check beforehand that AllocateAddress allocations are covered
by a single memory map entry, so that it either succeeds or fails
completely, rather than leaking allocations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-03-17 18:50:55 +00:00
..
Imem.h MdeModulePkg DxeCore: Return memory type from internal free pool/pages 2016-04-22 13:39:56 +08:00
MemData.c Update the copyright notice format 2010-04-24 09:49:11 +00:00
MemoryProfileRecord.c MdeModulePkg DxeCore: Remove unreferenced symbol for memory profile 2017-03-15 16:47:20 +08:00
Page.c MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries 2017-03-17 18:50:55 +00:00
Pool.c MdeModulePkg/DxeCore: Fix coding style issues 2017-03-07 21:47:25 +08:00