RE: Accounting for vmap_area object growth when kmemleak doesn't notice any leaks

["Preble, Adam C" <adam.c.preble@intel.com>]

I meant to send a thanks for this, but I got mired in trying to understand the result. I saved /proc/allocinfo before and after a test interval and wrote a script to correlate and compare the change in sizes between the two files. There is definitely growth across the test interval, but I cannot trace it back to my own kernel code with stuff like bpftrace dumping kstacks on or near the given functions (as some of them can't be directly traced). So I've had to reach out in different directions figure out what's going on. It didn't help that this was my first introduction to folios and filemaps.

If anybody is curious, my biggest ones are:

    Growth    NewSize TagInfo
============================================================
  39407616  109314048 mm/readahead.c:186 func:ractl_alloc_folio
  35815424   36634624 mm/memory.c:464 func:__pte_alloc_kernel
  34979840  556675072 mm/slub.c:2492 func:alloc_slab_page
   9523200   12398592 mm/filemap.c:1981 func:__filemap_get_folio

Anyways, thanks!

-----Original Message-----
From: Lance Yang <lance.yang@linux.dev> 
Sent: Friday, October 31, 2025 1:46 AM
To: Preble, Adam C <adam.c.preble@intel.com>
Cc: linux-mm@kvack.org; Lance Yang <ioworker0@gmail.com>
Subject: Re: Accounting for vmap_area object growth when kmemleak doesn't notice any leaks

From: Lance Yang <ioworker0@gmail.com>

That's a tricky one. With kmemleak being clean, it seems like a logical leak.

Might be worth enabling CONFIG_MEM_ALLOC_PROFILING[1], which is perfect for tracking down the call sites of allocations that are still live.

[1] https://docs.kernel.org/mm/allocation-profiling.html

Cheers,
Lance