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
