On Wed, 26 Dec 2018 at 03:35, Qian Cai <cai@xxxxxx> wrote: > > a0fc5578f1d (efi: Let kmemleak ignore false positives) is no longer > needed due to efi_mem_reserve_persistent() uses __get_free_page() > instead where kmemelak is not able to track regardless. Otherwise, > kernel reported "kmemleak: Trying to color unknown object at > 0xffff801060ef0000 as Black" > > Signed-off-by: Qian Cai <cai@xxxxxx> Why are you sending this to -mmotm? Andrew, please disregard this patch. This is EFI/tip material. > --- > drivers/firmware/efi/efi.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 7ac09dd8f268..4c46ff6f2242 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -31,7 +31,6 @@ > #include <linux/acpi.h> > #include <linux/ucs2_string.h> > #include <linux/memblock.h> > -#include <linux/kmemleak.h> > > #include <asm/early_ioremap.h> > > @@ -1027,8 +1026,6 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) > if (!rsv) > return -ENOMEM; > > - kmemleak_ignore(rsv); > - > rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE); > atomic_set(&rsv->count, 1); > rsv->entry[0].base = addr; The patch that adds the kmemleak_ignore() call here is queued in efi/urgent branch in the tip tree, but did not make it into v4.20. efi/urgent does not apply cleanly to efi/core, since the kmalloc() call [which requires the kmemleak_ignore() call] has been replaced with alloc_pages() [which doesn't], necessitating this patch to remove the kmemleak_ignore() call again. So what I would like to suggest is that Ingo resolves this conflict by simply dropping the call to kmemleak_ignore(). That way, we don't need this patch, and we can still backport the efi/urgent change to v4.20-stable.
