diff options
author | jgong5 <jgong5@6f19259b-4bc3-4df7-8a09-765794883524> | 2010-04-03 05:34:16 +0000 |
---|---|---|
committer | jgong5 <jgong5@6f19259b-4bc3-4df7-8a09-765794883524> | 2010-04-03 05:34:16 +0000 |
commit | 38c7df9848811c2a6e6ed11fd78ba0e19215e77c (patch) | |
tree | 34ca11409ada76da89f8634c56b1e5e79d81b1fe /EdkCompatibilityPkg/EdkCompatibilityPkg.dsc | |
parent | 969eba7b0df70c9aa261eaf005085568b88de87c (diff) | |
download | edk2-platforms-38c7df9848811c2a6e6ed11fd78ba0e19215e77c.tar.xz |
Avoid DEBUG_CLEAR_MEMORY clearing MemoryMap internal structure.
In CoreFreePages(), the following sequence might break the MemoryMap internal structure:
CoreConvertPages() -> CoreFreeMemoryMapStack() -> AllocateMemoryMapEntry() -> CoreAllocatePoolPages() -> DEBUG_CLEAR_MEMORY()
CoreConvertPages() will call CoreFreeMemoryMapStack() after it adds the freed memory range, so the latter might use the just freed memory range when calling AllocateMemoryMapEntry(). But CoreFreePages() will call DEBUG_CLEAR_MEMORY() after CoreConvertPages(). This might clear up the memory map entry structure.
The fix calls DEBUG_CLEAR_MEMORY() just after freed memory range is added in CoreConvertPages(), which is safe.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10335 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'EdkCompatibilityPkg/EdkCompatibilityPkg.dsc')
0 files changed, 0 insertions, 0 deletions