From: Matt Mackall <mpm@selenic.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Paul Mundt <lethal@linux-sh.org>, Nick Piggin <npiggin@kernel.dk>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] slob/lockdep: Fix gfp flags passed to lockdep
Date: Tue, 07 Jun 2011 07:49:06 -0500 [thread overview]
Message-ID: <1307450946.4204.952.camel@calx> (raw)
In-Reply-To: <BANLkTinUcZFW6-GKQgWn-KhzEA0Qbaz8PA@mail.gmail.com>
On Tue, 2011-06-07 at 14:54 +0300, Pekka Enberg wrote:
> On Tue, Jun 7, 2011 at 2:18 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Doing a ktest.pl randconfig, I stumbled across the following bug
> > on boot up:
> >
> > ------------[ cut here ]------------
> > WARNING: at /home/rostedt/work/autotest/nobackup/linux-test.git/kernel/lockdep.c:2649 lockdep_trace_alloc+0xed/0x100()
> > Hardware name:
> > Modules linked in:
> > Pid: 0, comm: swapper Not tainted 3.0.0-rc1-test-00054-g1d68b67 #1
> > Call Trace:
> > [<ffffffff810626ad>] warn_slowpath_common+0xad/0xf0
> > [<ffffffff8106270a>] warn_slowpath_null+0x1a/0x20
> > [<ffffffff810b537d>] lockdep_trace_alloc+0xed/0x100
> > [<ffffffff81182fb0>] __kmalloc_node+0x30/0x2f0
> > [<ffffffff81153eda>] pcpu_mem_alloc+0x13a/0x180
> > [<ffffffff82be022c>] percpu_init_late+0x48/0xc2
> > [<ffffffff82bd630c>] ? mem_init+0xd8/0xe3
> > [<ffffffff82bbcc73>] start_kernel+0x1c2/0x449
> > [<ffffffff82bbc35c>] x86_64_start_reservations+0x163/0x167
> > [<ffffffff82bbc493>] x86_64_start_kernel+0x133/0x142^M
> > ---[ end trace a7919e7f17c0a725 ]---
> >
> > Then I ran a ktest.pl config_bisect and it came up with this config
> > as the problem:
> >
> > CONFIG_SLOB
> >
> > Looking at what is different between SLOB and SLAB and SLUB, I found
> > that the gfp flags are masked against gfp_allowed_mask in
> > SLAB and SLUB, but not SLOB.
> >
> > On boot up, interrupts are disabled and lockdep will warn if some flags
> > are set in gfp and interrupts are disabled. But these flags are masked
> > off with the gfp_allowed_mask during boot. Because SLOB does not
> > mask the flags against gfp_allowed_mask it triggers the warn on.
> >
> > Adding this mask fixes the bug. I also found that kmem_cache_alloc_node()
> > was missing both the mask and the lockdep check, and that was added too.
> >
> > Cc: Matt Mackall <mpm@selenic.com>
> > Cc: Paul Mundt <lethal@linux-sh.org>
> > Cc: Nick Piggin <npiggin@kernel.dk>
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> >
> > diff --git a/mm/slob.c b/mm/slob.c
> > index 46e0aee..0ae8818 100644
> > --- a/mm/slob.c
> > +++ b/mm/slob.c
> > @@ -482,6 +482,8 @@ void *__kmalloc_node(size_t size, gfp_t gfp, int node)
> > int align = max(ARCH_KMALLOC_MINALIGN, ARCH_SLAB_MINALIGN);
> > void *ret;
> >
> > + gfp &= gfp_allowed_mask;
> > +
> > lockdep_trace_alloc(gfp);
> >
> > if (size < PAGE_SIZE - align) {
> > @@ -608,6 +610,10 @@ void *kmem_cache_alloc_node(struct kmem_cache *c, gfp_t flags, int node)
> > {
> > void *b;
> >
> > + flags &= gfp_allowed_mask;
> > +
> > + lockdep_trace_alloc(flags);
> > +
> > if (c->size < PAGE_SIZE) {
> > b = slob_alloc(c->size, flags, c->align, node);
> > trace_kmem_cache_alloc_node(_RET_IP_, b, c->size,
>
> Matt, any objections to merging this?
Looks good.
Acked-by: Matt Mackall <mpm@selenic.com>
--
Mathematics is the supreme nostalgia of our time.
prev parent reply other threads:[~2011-06-07 12:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-07 11:18 [PATCH] slob/lockdep: Fix gfp flags passed to lockdep Steven Rostedt
2011-06-07 11:54 ` Pekka Enberg
2011-06-07 12:49 ` Matt Mackall [this message]
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=1307450946.4204.952.camel@calx \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@kernel.dk \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.