Kmemleak and debug objects

[Evgenii Shatokhin]

Hi,

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  ........./.'....
  backtrace:
    [<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?

Regards,
Evgenii