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 protected]>
