Hi Rustam, On Mon, Jun 14, 2021 at 01:31:14PM -0700, Rustam Kovhaev wrote: > a) kmemleak scans struct page (kmemleak.c:1462), but it does not scan > the actual contents (page_address(page)) of the page. > if we allocate an object with kmalloc(), then allocate page with > alloc_page(), and if we put kmalloc pointer somewhere inside that page, > kmemleak will report kmalloc pointer as a false positive. > should we improve kmemleak and make it scan page contents? > or will this bring too many false negatives? This is indeed on purpose otherwise (1) we'd get a lot of false negatives and (2) the scanning would take significantly longer. There are a lot more pages allocated for user processes than used in the kernel, we don't need to scan them all. We do have a few places where we explicitly call kmemleak_alloc(): neigh_hash_alloc(), alloc_page_ext(), blk_mq_alloc_rqs(), early_amd_iommu_init(). > b) when kmemleak object gets created (kmemleak.c:598) it gets checksum > of 0, by the time user requests kmemleak "scan" via debugfs the pointer > will be most likely changed to some value by the kernel and during > first scan kmemleak won't report the object as orphan even if it did not > find any reference to it, because it will execute update_checksum() and > after that will proceed to updating object->count (kmemleak.c:1502). > and so the user will have to initiate a second "scan" via debugfs and > only then kmemleak will produce the report. > should we document this? That's a mitigation against false positives. Lot's of objects that get allocated just prior to a memory scan have a tendency to be reported as leaks before they get referenced via e.g. a list (and the in-object list_head structure updated). So you'd need to get the checksum identical in two consecutive scans to report it as a leak. We should probably document this. -- Catalin
