linux-kernel - Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161 check

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1255596350.10164.11.camel@pc1117.cambridge.arm.com>
Date:	Thu, 15 Oct 2009 09:45:50 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [2.6.32-rc3 kmemleak] WARNING: at kernel/lockdep.c:3161
	check_flags+0xbe/0x180()

On Thu, 2009-10-15 at 12:52 +0900, Tetsuo Handa wrote:
> Catalin Marinas wrote:
> > Could you check the object_cache->obj_size/buffer_size and
> > scan_area_cache->obj_size/buffer_size in mm/kmemleak.c? The first
> > impression is that these somehow are too big when they shouldn't.
> > 
> > From your .config, you have DEBUG_PAGEALLOC enabled which may set
> > buffer_size to a full PAGE_SIZE. This size also enables the off slab
> > mgmt data.
> 
> Yes. object_cache->buffer_size was set to PAGE_SIZE.
> 
> [    0.000000] ***** object_cache->obj_size = 200 *****
> [    0.000000] ***** object_cache->buffer_size = 4096 *****
> [    0.000000] ***** scan_area_cache->obj_size = 16 *****
> [    0.000000] ***** scan_area_cache->buffer_size = 40 *****
> 
> I thought we should also pass SLAB_PANIC flag to
> 
> 	object_cache = KMEM_CACHE(kmemleak_object, SLAB_NOLEAKTRACE);
> 	scan_area_cache = KMEM_CACHE(kmemleak_scan_area, SLAB_NOLEAKTRACE);

I think it would be better to disable kmemleak than panicking.

> Don't we need to disable kmemleak routine (call kmemleak_disable()?)
> when early_alloc() failed in order to avoid false positives?

This is already done in create_object() via kmemleak_stop().

> I got below entries.
> (Similar entries are posted at http://lkml.org/lkml/2009/10/14/571 )

As a general rule with kmemleak, it would be useful to run a few "echo
scan > /sys/kernel/debug/kmemleak" to make sure they are not just
transient false positives.

> unreferenced object 0xf703d460 (size 24):
>   comm "swapper", pid 0, jiffies 4294892296
>   hex dump (first 24 bytes):
>     00 00 00 00 e8 97 c7 c1 02 00 00 00 1c 1e 21 d5  ..............!.
>     0c 93 4c c1 00 00 00 00                          ..L.....
>   backtrace:
>     [<c10d3944>] create_object+0xe4/0x220
>     [<c13226b3>] kmemleak_alloc+0x83/0xd0
>     [<c10cff55>] kmem_cache_alloc+0x185/0x1d0
>     [<c11b8d7d>] debug_objects_replace_static_objects+0x2d/0x1a0
>     [<c1518e34>] debug_objects_mem_init+0x64/0x70
>     [<c14f9974>] start_kernel+0x194/0x290
>     [<c14f9095>] i386_start_kernel+0x65/0xa0
>     [<ffffffff>] 0xffffffff

I get these reports as well and I think they are false positives. I
looked at the code in question and couldn't figure out why kmemleak is
confused.

> However, after doing
> 
>   # echo scan > /sys/kernel/debug/kmemleak
> 
> /sys/kernel/debug/kmemleak became empty.
> Does this mean that above entries were not memory leak?

Yes, they are just some transient memory leaks. This is usually caused
by the fact that kmemleak doesn't stop the allocations when scanning
(many garbage collectors do this). There are very few cases of false
positives left and debug_objects is one of them

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/