Moving Ard and Dan to To:
On Wed, Jun 05, 2024 at 10:28:18AM +0800, Dave Young wrote:
> Ok, thanks! I think the right way is creating two patches, one to
> remove the __efi_memmap_free,
Yap, that
f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks")
needs revisiting.
So AFAIU, the flow is this:
In a kexec-ed kernel:
1. efi_arch_mem_reserve() gets called by bgrt, erst, mokvar... whatever
to hold on to boot services regions for longer otherwise EFI
"implementations" explode.
2. On same kexec-ed kernel, we call into kexec_enter_virtual_mode()
because it needs to get the runtime services regions from the first
kernel
3. As part of that call, it'll do
efi_memmap_init_late->__efi_memmap_init():
if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB))
__efi_memmap_free(efi.memmap.phys_map,
and the memory which got allocated in step 1 is gone, thus reverting
what efi_arch_mem_reserve() is trying to fix.
IOW, we need a
EFI_MEMMAP_DO_NOT_TOUCH_MY_MEMORY
flag which'll stop this from happening. But I'd prefer it if Ard decides
what the right thing to do here is.
> another is skip efi_arch_mem_reserve when the EFI_MEMORY_RUNTIME bit
> was set already.
Can that even happen?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
