Re: [PATCH v1] Revert "mm: kmemleak: alloc gray object for reserved region with direct map"

[Isaac Manjarres <isaacmanjarres@google.com>]

On Wed, Jan 25, 2023 at 03:02:15PM -0600, Rob Herring wrote:
> On Tue, Jan 24, 2023 at 03:02:54PM -0800, Isaac J. Manjarres wrote:
> > This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.
> > 
> > Kmemleak operates by periodically scanning memory regions for pointers
> > to allocated memory blocks to determine if they are leaked or not.
> > However, reserved memory regions can be used for DMA transactions
> > between a device and a CPU, and thus, wouldn't contain pointers to
> > allocated memory blocks, making them inappropriate for kmemleak to
> > scan. Thus, revert this commit.
> 
> Both commits talk about the same type of memory as CMA is used for DMA. 
> Neither commit tells me what are the implications of kmemleak scanning 
> or not scanning the region? Are there false positives?
If kmemleak scans the region when CONFIG_DEBUG_PAGEALLOC is enabled,
and the CMA region is not in use, then kmemleak will cause a page-fault,
because the region is unmapped from the kernel's address space. kmemleak
scans the region because it thinks it is in use/allocated, when it's
not. While this sounds like a problem of kmemleak not being informed
about the region not being actually allocated, it's also a matter of CMA
regions not being suitable for kmemleak to scan in the first place,
because they don't have pointers to other memory blocks; they might have
data from DMA transactions with another device, so it doesn't make
sense for kmemleak to scan these areas.

--Isaac