Subject: Re: [PATCH 4/8] mm/bootmem_info: remove call to kmemleak_free_part_phys()

From: Lance Yang <[email-masked]>
Date: Wed, 20 May 2026 20:15:05 +0800

On Tue, May 12, 2026 at 10:45:03AM +0200, David Hildenbrand (Arm) wrote:
>On 5/12/26 10:34, Oscar Salvador wrote:
[...]
>>> 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 <[email-masked]>