On 12/7/18 at 6:28 AM, Ard Biesheuvel wrote: > On Thu, 6 Dec 2018 at 19:05, Qian Cai <cai@xxxxxx> wrote: > > > > On Thu, 2018-12-06 at 19:01 +0100, Ard Biesheuvel wrote: > > > On Thu, 6 Dec 2018 at 19:00, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > > > > > > On Thu, Dec 06, 2018 at 11:16:33AM -0500, Qian Cai wrote: > > > > > unreferenced object 0xffff8096c1acf580 (size 128): > > > > > comm "swapper/63", pid 0, jiffies 4294937418 (age 1201.230s) > > > > > hex dump (first 32 bytes): > > > > > 80 87 b5 c1 96 00 00 00 00 00 cc c2 16 00 00 00 ................ > > > > > 00 00 01 00 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk > > > > > backtrace: > > > > > [<000000001d2549ba>] kmem_cache_alloc_trace+0x430/0x500 > > > > > [<0000000093a6dfab>] efi_mem_reserve_persistent+0x50/0xf8 > > > > > [<000000000a730828>] its_cpu_init_lpis+0x394/0x4b8 > > > > > [<00000000edf04e07>] its_cpu_init+0x104/0x150 > > > > > [<000000004d0342c5>] gic_starting_cpu+0x34/0x40 > > > > > [<000000005d9da772>] cpuhp_invoke_callback+0x228/0x1d68 > > > > > [<0000000061eace9b>] notify_cpu_starting+0xc0/0x118 > > > > > [<0000000048bc2dc5>] secondary_start_kernel+0x23c/0x3b0 > > > > > [<0000000015137d6a>] 0xffffffffffffffff > > > > > > > > > > efi_mem_reserve_persistent+0x50/0xf8: > > > > > kmalloc at include/linux/slab.h:546 > > > > > (inlined by) efi_mem_reserve_persistent at drivers/firmware/efi/efi.c:979 > > > > > > > > > > This line, > > > > > > > > > > rsv = kmalloc(sizeof(*rsv), GFP_ATOMIC); > > > > > > > > > > Kmemleak has a known limitation that can only track pointers in the kernel > > > > > virtual space. Hence, it will report false positives due to "rsv" will > > > > > only > > > > > reference to other physical addresses, > > > > > > > > > > rsv->next = efi_memreserve_root->next; > > > > > efi_memreserve_root->next = __pa(rsv); > > > > > > > > > > Signed-off-by: Qian Cai <cai@xxxxxx> > > > > > > > > Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx>\ > > > > > > I don't see the patch and I wasn't cc'ed > > > > That is strange. Please see, > > > > https://lore.kernel.org/lkml/1543517152-23969-1-git-send-email-cai@xxxxxx/ > > OK, I found it in my spam folder, apologies for that. > > This kmalloc() will be replaced in the next merge window by a call to > __get_free_page(). Does kmemleak still require the kmemleak_ignore() > for that case? Or is it only for kmalloc()? Looks like kmemleak won’t be able to track page allocation, so it should be fine then without kmemleak_ignore().
