The kmemleak code sometimes complains about the following leak: unreferenced object 0xffff8000102e0000 (size 32768): comm "swapper/0", pid 1, jiffies 4294937323 (age 71.240s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000db9a88a3>] __vmalloc_node_range+0x324/0x450 [<00000000ff8903a4>] __vmalloc_node+0x90/0xd0 [<000000001a06634f>] arm64_efi_rt_init+0x64/0xdc [<0000000007826a8d>] do_one_initcall+0x178/0xac0 [<0000000054a87017>] do_initcalls+0x190/0x1d0 [<00000000308092d0>] kernel_init_freeable+0x2c0/0x2f0 [<000000003e7b99e0>] kernel_init+0x28/0x14c [<000000002246af5b>] ret_from_fork+0x10/0x20 The memory object in this case is for efi_rt_stack_top and is allocated in an initcall. So this is certainly a false positive. Mark the object as not a leak to quash it. Signed-off-by: Waiman Long <longman@xxxxxxxxxx> --- arch/arm64/kernel/efi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index 4a92096db34e..712718aed5dd 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -9,6 +9,7 @@ #include <linux/efi.h> #include <linux/init.h> +#include <linux/kmemleak.h> #include <linux/screen_info.h> #include <linux/vmalloc.h> @@ -213,6 +214,7 @@ l: if (!p) { return -ENOMEM; } + kmemleak_not_leak(p); efi_rt_stack_top = p + THREAD_SIZE; return 0; } -- 2.39.3