Kmemleak and debug objects
From: Evgenii Shatokhin
Date: Fri Jan 22 2016 - 06:02:28 EST
When using Kmemleak on the kernel 3.10.0-229.7.2 x86_64 (RHEL 7 and the
like) with CONFIG_DEBUG_OBJECTS=y, I sometimes see Kmemleak report the
potential leaks of the following kind:
unreferenced object 0xffff8800270e32d0 (size 40):
comm "updatedb", pid 14416, jiffies 4297905695 (age 4024.651s)
hex dump (first 32 bytes):
c0 2a 0e 27 00 88 ff ff f0 38 5c 84 ff ff ff ff .*.'.....8\.....
01 00 00 00 00 00 00 00 10 2f be 27 00 88 ff ff ........./.'....
[<ffffffffa04a89a6>] ext4_alloc_inode+0x5c6/0x7f0 [ext4]
[<ffffffffa0448332>] ext4_iget+0x112/0x46f0 [ext4]
[<ffffffffa044c998>] ext4_iget_normal+0x88/0xb0 [ext4]
[<ffffffffa047149e>] ext4_lookup+0x29e/0x4e0 [ext4]
If I trigger Kmemleak scan again, such objects are still reported in
The object is an instance of 'struct debug_obj' and the first two 8-byte
fields of it are the contents of 'struct hlist_node' (next, *pprev).
The object should be in a bucket of obj_hash (lib/debugobjects.c),
namely the one at 0xffffffff845c38f0, as I can see from hlist_node::pprev.
I checked the memory - that element of obj_hash did actually contain the
pointer to that object after Kmemleak had reported it as a potential leak.
Kmemleak scans the memory areas from .bss, including obj_hash, so it
should probably have seen that pointer.
Looks like a false positive.
Is it a known problem?
Could it be that Kmemleak, say, saw that object after that had been
allocated and removed from obj_pool but before it had been added to
obj_hash? However, the subsequent scans would have shown in that case
that the object is not leaked, I guess. Or, perhaps, something else