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