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 ........./.'....
[<ffffffff82355fbe>] kmemleak_alloc+0x4e/0xc0
[<ffffffff8156fc15>] kmem_cache_alloc+0x125/0x390
[<ffffffff8192091d>] __debug_object_init+0x6bd/0xc40
[<ffffffff81920ebb>] debug_object_init+0x1b/0x20
[<ffffffff811adf89>] __init_work+0x19/0x30
[<ffffffffa04a89a6>] ext4_alloc_inode+0x5c6/0x7f0 [ext4]
[<ffffffff8161777b>] alloc_inode+0x5b/0x170
[<ffffffff8161bb6b>] iget_locked+0xfb/0x2f0
[<ffffffffa0448332>] ext4_iget+0x112/0x46f0 [ext4]
[<ffffffffa044c998>] ext4_iget_normal+0x88/0xb0 [ext4]
[<ffffffffa047149e>] ext4_lookup+0x29e/0x4e0 [ext4]
[<ffffffff815df8d0>] lookup_real+0x90/0x120
[<ffffffff815e1243>] __lookup_hash+0xe3/0x100
[<ffffffff815e1d42>] lookup_slow+0xd2/0x280
[<ffffffff815f1266>] path_lookupat+0x1ec6/0x4610
[<ffffffff815f39fc>] filename_lookup+0x4c/0x1f0

If I trigger Kmemleak scan again, such objects are still reported in /sys/kernel/debug/kmemleak.

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 causes this?

Any ideas?