linux-kernel - Re: [WARNING] lockdep and kmemcheck_alloc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1337485947.4107.295.camel@deadeye>
Date:	Sun, 20 May 2012 04:52:27 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Christoph Lameter <cl@...ux.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	stable <stable@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [WARNING] lockdep and kmemcheck_alloc_shadow

On Sat, 2012-05-19 at 13:47 -0400, Steven Rostedt wrote:
> Testing 3.2.18-rc1 I hit the following:
> 
> WARNING: at /work/autotest/nobackup/linux-test.git/kernel/lockdep.c:2739 lockdep_trace_alloc+0xee/0xf0()

Which is:

	/*
	 * Oi! Can't be having __GFP_FS allocations with IRQs disabled.
	 */
	if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
		return;

> Hardware name:         
> Pid: 0, comm: swapper/0 Not tainted 3.2.18-rc1-test+ #1
> Call Trace:^M
>  [<ffffffff81066175>] warn_slowpath_common+0x75/0xb0
>  [<ffffffff81066285>] warn_slowpath_null+0x15/0x20
>  [<ffffffff81098aee>] lockdep_trace_alloc+0xee/0xf0
>  [<ffffffff810d8adc>] __alloc_pages_nodemask+0x8c/0x7e0
>  [<ffffffff81098537>] ? trace_hardirqs_off_caller+0xb7/0x120
>  [<ffffffff8143467d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
>  [<ffffffff81098537>] ? trace_hardirqs_off_caller+0xb7/0x120
>  [<ffffffff8143467d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
>  [<ffffffff81098537>] ? trace_hardirqs_off_caller+0xb7/0x120
>  [<ffffffff8143467d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
>  [<ffffffff81c8d567>] ? retint_restore_args+0x6/0x13
>  [<ffffffff81113c9b>] kmemcheck_alloc_shadow+0x4b/0xf0
>  [<ffffffff8111016f>] new_slab+0x26f/0x370
>  [<ffffffff81c70677>] __slab_alloc+0x2ee/0x421
>  [<ffffffff8143467d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
>  [<ffffffff8110997e>] ? do_set_mempolicy+0x4e/0x210^M
>  [<ffffffff81c8d567>] ? retint_restore_args+0x6/0x13
>  [<ffffffff8110997e>] ? do_set_mempolicy+0x4e/0x210
>  [<ffffffff8111122d>] kmem_cache_alloc+0x12d/0x140
>  [<ffffffff8110997e>] do_set_mempolicy+0x4e/0x210
>  [<ffffffff822e945e>] numa_policy_init+0x11f/0x13f
>  [<ffffffff822c7aae>] start_kernel+0x2d0/0x36e
[...]

Seems to be a bug in SLUB:

> static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
> {
[...]
> 	if (flags & __GFP_WAIT)
> 		local_irq_disable();
> 
> 	if (!page)
> 		return NULL;
> 
> 	if (kmemcheck_enabled
> 		&& !(s->flags & (SLAB_NOTRACK | DEBUG_DEFAULT_FLAGS))) {
> 		int pages = 1 << oo_order(oo);
> 
> 		kmemcheck_alloc_shadow(page, oo_order(oo), flags, node);
[...]

So kmemcheck_alloc_shadow() runs with IRQs off, but uses the same flags
as the original allocation.

Looks like this was introduced by:

commit 7e0528dadc9f8b04e4de0dba48a075100c2afe75
Author: Christoph Lameter <cl@...ux.com>
Date:   Wed Jun 1 12:25:44 2011 -0500

    slub: Push irq disable into allocate_slab()

which went into 3.1.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
                                                         - Carolyn Scheppner

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)