| Message ID | 20240613162031.142224-1-longman@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64/efi: Fix kmemleak false positive in arm64_efi_rt_init() | expand |
On Thu, 13 Jun 2024 at 18:21, Waiman Long <longman@redhat.com> wrote: > > 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@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> I'll take this as a fix via the EFI tree. Thanks, > --- > 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 > >
On Thu, Jun 13, 2024 at 12:20:31PM -0400, Waiman Long wrote: > 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; It looks like a false positive and the reason is that we only store p + THREAD_SIZE in efi_rt_stack_top, not the actual allocated pointer.
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; }
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@redhat.com> --- arch/arm64/kernel/efi.c | 2 ++ 1 file changed, 2 insertions(+)