On Tue, May 12, 2026 at 10:45:03AM +0200, David Hildenbrand (Arm) wrote:

On 5/12/26 10:34, Oscar Salvador wrote:

[...]

quoted

quoted

diff --git a/mm/bootmem_info.c b/mm/bootmem_info.c
index 6e2aaab3dca9..74c1116626c8 100644
--- a/mm/bootmem_info.c
+++ b/mm/bootmem_info.c

@@ -32,7 +32,6 @@ void put_page_bootmem(struct page *page)
 
 	if (page_ref_dec_return(page) == 1) {
 		set_page_private(page, 0);
-		kmemleak_free_part_phys(PFN_PHYS(page_to_pfn(page)), PAGE_SIZE);

A bit odd that kmemleak_free_part_phys() did not complain if we never
did kmemleak_alloc_phys() for these pages?

delete_object_part() calls __find_and_remove_object() and essentially just skips
if it didn't find anything.

Maybe the kmemleak_warn() would trigger, but it's guarded by "#ifdef DEBUG" ...

Right! With kmemleak DEBUG enabled, kmemleak_free_part_phys() does warns
whenever delete_object_part() cannot find the corresponding physical
object ...

Before this patch, booting with:

"kmemleak=on hugetlb_free_vmemmap=on default_hugepagesz=2M hugepagesz=2M hugepages=512"

I got a lot of warnings, something like:

[   44.481883] kmemleak: Partially freeing unknown object at 0x2acc59000 (size 4096)
[   44.482754] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc3 #206 PREEMPT(full)
[   44.482758] Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
[   44.482760] Call Trace:
[   44.482762]  <TASK>
[   44.482764]  dump_stack_lvl+0x60/0x90
[   44.482769]  dump_stack+0x14/0x1a
[   44.482774]  delete_object_part.cold+0x28/0x2d
[   44.482779]  kmemleak_free_part_phys+0x67/0x80
[   44.482783]  put_page_bootmem+0xc0/0x100
[   44.482787]  free_vmemmap_page_list+0x13e/0x230
[   44.482791]  __hugetlb_vmemmap_optimize_folios+0x351/0x430
[...]

So, yeah, looks like these calls are trying to free physical kmemleak
objects that are no longer tracked after memmap_alloc() started using
MEMBLOCK_ALLOC_NOLEAKTRACE :)

With this patch applied, those stale calls are gone, and so are the
warnings :P

Tested-by: Lance Yang <lance.yang@linux.dev>