From: Ben Hutchings <ben@decadent.org.uk>
To: Steven Rostedt <rostedt@goodmis.org>, Christoph Lameter <cl@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
stable <stable@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [WARNING] lockdep and kmemcheck_alloc_shadow
Date: Sun, 20 May 2012 04:52:27 +0100 [thread overview]
Message-ID: <1337485947.4107.295.camel@deadeye> (raw)
In-Reply-To: <1337449661.32434.4.camel@gandalf.stny.rr.com>
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]
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@linux.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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-05-20 3:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-19 17:47 [WARNING] lockdep and kmemcheck_alloc_shadow Steven Rostedt
2012-05-20 3:52 ` Ben Hutchings [this message]
2012-05-20 21:10 ` David Rientjes
2012-06-11 9:56 ` David Rientjes
2012-06-11 11:04 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1337485947.4107.295.camel@deadeye \
--to=ben@decadent.org.uk \
--cc=cl@linux.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).