On 01/05/17 at 08:42am, Ingo Molnar wrote: > > * Nicolai Stange <[email protected]> wrote: > > > Matt Fleming <[email protected]> writes: > > > > > On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote: > > >> So, after memblock is gone, allocations should be done through the > > >> "normal" > > >> page allocator. Introduce a helper, efi_memmap_alloc() for this. Use > > >> it from efi_arch_mem_reserve() and from efi_free_boot_services() as well. > > >> > > >> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid > > >> copying image data") > > >> Signed-off-by: Nicolai Stange <[email protected]> > > > > > Could you also modify efi_fake_memmap() to use your new > > > efi_memmap_alloc() function for consistency > > > > Sure. > > > > I'm planning to submit another set of patches addressing the (bounded) > > memmap leaking in anything calling efi_memmap_unmap() though. In the > > course of doing so, the memmap allocation sites will get touched anyway: > > I'll have to store some information about how the memmap's memory has > > been obtained. > > Will that patch be intrusive? > > If yes then we'll need to keep this a separate urgent patch to fix the v4.9 > regression that Dan Williams reported. I can apply the fix to efi/urgent and > get > it to Linus straight away if you guys agree.
Ditto question to Matt as I asked in reply to patch 2/2, can we move the efi_mem_reserve to early code so that memblock is still usable and consider to improve it in other way later? > > Thanks, > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html
