From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753055AbcAVLCZ (ORCPT ); Fri, 22 Jan 2016 06:02:25 -0500 Received: from forward18m.cmail.yandex.net ([5.255.216.149]:54585 "EHLO forward18m.cmail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752814AbcAVLBz (ORCPT ); Fri, 22 Jan 2016 06:01:55 -0500 X-Greylist: delayed 446 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Jan 2016 06:01:55 EST Authentication-Results: smtp4m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-ForeignMX: GB From: Evgenii Shatokhin Subject: Kmemleak and debug objects To: Catalin Marinas Cc: LKML Message-ID: <56A20A61.9050804@yandex.ru> Date: Fri, 22 Jan 2016 13:54:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: [] kmemleak_alloc+0x4e/0xc0 [] kmem_cache_alloc+0x125/0x390 [] __debug_object_init+0x6bd/0xc40 [] debug_object_init+0x1b/0x20 [] __init_work+0x19/0x30 [] ext4_alloc_inode+0x5c6/0x7f0 [ext4] [] alloc_inode+0x5b/0x170 [] iget_locked+0xfb/0x2f0 [] ext4_iget+0x112/0x46f0 [ext4] [] ext4_iget_normal+0x88/0xb0 [ext4] [] ext4_lookup+0x29e/0x4e0 [ext4] [] lookup_real+0x90/0x120 [] __lookup_hash+0xe3/0x100 [] lookup_slow+0xd2/0x280 [] path_lookupat+0x1ec6/0x4610 [] 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