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

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

[Preble, Adam C]

Assuming I don't see any leaks from kmemleak, but I see objects growing from the vmap_area slab allocator, how could I account for the growth? Is it a leak? If so, how could I isolate them when kmemleak doesn't notice anything?

I have a workload involving an external kernel module providing a filesystem (no actual physical device) that had some leaks that kmemleak spotted and I fixed. I still eventually (very slowly now) crash the kernel by running out of memory. The only real peculiar thing I noticed is that the vmap_area slab allocator in /proc/slabinfo continues to show growth into the hundreds of thousands of objects. The workload involves loading the module, mounting the file system, running some tests, unmounting the filesystem, and ultimately unloading the module. That should reclaim everything it was doing, and I don't think I'm seeing virtual memory fragmentation since the buddy allocator seems to stabilize on a proportion of sizes (disregarding it slowly trending to the smallest size due to simply running out of total memory).

I guess I should add that /proc/meminfo shows the used vmalloc'd memory as stable this whole time. It doesn't increase. Total slab memory used does slowly rise.

I have tried to track allocations and frees to vmap area with bpftrace. I have a kretprobe on __vmalloc_node_range_noprof to hash the allocated pointer to the kernel stack, and I remove the entry when the address comes up on kprobes on kvfree and vfree. I get a few entries this way to kernel_clone()->copy_process() that I have to sort out, but I need to emphasize kmemleak doesn't point out a problem there. So I don't know if I'm just picking up some end-of-run chatter or something.

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

[Lance Yang]

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

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

[Preble, Adam C]

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