From: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>
To: "Vegard Nossum" <vegard.nossum@gmail.com>
Cc: "Pekka Enberg" <penberg@cs.helsinki.fi>,
"Christoph Lameter" <clameter@sgi.com>,
Yanmin <yanmin_zhang@linux.intel.com>,
"Rusty Russell" <rusty@rustcorp.com.au>,
"Ingo Molnar" <mingo@elte.hu>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Dhaval Giani" <dhaval@linux.vnet.ibm.com>,
"Gautham R Shenoy" <ego@in.ibm.com>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
miaox@cn.fujitsu.com, "Lai Jiangshan" <laijs@cn.fujitsu.com>,
"Avi Kivity" <avi@qumranet.com>,
linux-kernel@vger.kernel.org
Subject: Re: v2.6.26-rc9: kernel BUG at kernel/sched.c:5858!
Date: Thu, 10 Jul 2008 22:16:06 +0200 [thread overview]
Message-ID: <b647ffbd0807101316o97fe6d4p5b2cbcda472f2ae1@mail.gmail.com> (raw)
In-Reply-To: <19f34abd0807101249y24632b50h769a7af2c9514864@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]
2008/7/10 Vegard Nossum <vegard.nossum@gmail.com>:
> Okay, some more info on this one...
>
> On Thu, Jul 10, 2008 at 4:16 PM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
>> BUG: unable to handle kernel paging request at da87d000
>> IP: [<c01991c7>] kmem_cache_alloc+0xc7/0xe0
>> *pde = 28180163 *pte = 1a87d160
>> Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> Pid: 3850, comm: grep Not tainted (2.6.26-rc9-00059-gb190333 #5)
>> EIP: 0060:[<c01991c7>] EFLAGS: 00210203 CPU: 0
>> EIP is at kmem_cache_alloc+0xc7/0xe0
>> EAX: 00000000 EBX: da87c100 ECX: 1adad71a EDX: 6b6b6b6b
>> ESI: 00200282 EDI: da87d000 EBP: f60bfe74 ESP: f60bfe54
>> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>
> The register %ecx looks innocent but is very important here. The disassembly:
>
> mov %edx,%ecx
> shr $0x2,%ecx
> rep stos %eax,%es:(%edi) <-- the fault
>
> So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE.
> (0x6b6b6b6b >> 2 == 0x1adadada.)
>
> %ecx is the counter for the memset, from here:
>
> memset(object, 0, c->objsize);
>
> i.e. %ecx was loaded from c->objsize, so "c" must have been freed.
> Where did "c" come from? Uh-oh...
>
> c = get_cpu_slab(s, smp_processor_id());
>
> This looks like it has very much to do with CPU hotplug/unplug. Is
> there a race between SLUB/hotplug since the CPU slab is used after it
> has been freed?
Good analysis.
[ quick look ]
Yeah, it's possible that a caller of kmem_cache_alloc() ->
slab_alloc() can be migrated on another CPU right after
local_irq_restore() and before memset(). The inital cpu can become
offline in the mean time (or a migration is a consequence of the CPU
going offline) so its 'kmem_cache_cpu' structure gets freed (
slab_cpuup_callback).
At some point of time the caller continues on another CPU having an
obsolete pointer...
does something like this help?
diff --git a/mm/slub.c b/mm/slub.c
index 1a427c0..315c392 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1628,9 +1628,11 @@ static __always_inline void *slab_alloc(struct
kmem_cache *s,
void **object;
struct kmem_cache_cpu *c;
unsigned long flags;
+ unsigned int objsize;
local_irq_save(flags);
c = get_cpu_slab(s, smp_processor_id());
+ objsize = c->objsize;
if (unlikely(!c->freelist || !node_match(c, node)))
object = __slab_alloc(s, gfpflags, node, addr, c);
@@ -1643,7 +1645,7 @@ static __always_inline void *slab_alloc(struct
kmem_cache *s,
local_irq_restore(flags);
if (unlikely((gfpflags & __GFP_ZERO) && object))
- memset(object, 0, c->objsize);
+ memset(object, 0, objsize);
return object;
}
>
>
> Vegard
>
> --
> "The animistic metaphor of the bug that maliciously sneaked in while
> the programmer was not looking is intellectually dishonest as it
> disguises that the error is the programmer's own creation."
> -- E. W. Dijkstra, EWD1036
>
--
Best regards,
Dmitry Adamushko
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 002-fix-slub-hotplug.patch --]
[-- Type: text/x-diff; name=002-fix-slub-hotplug.patch, Size: 730 bytes --]
diff --git a/mm/slub.c b/mm/slub.c
index 1a427c0..315c392 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1628,9 +1628,11 @@ static __always_inline void *slab_alloc(struct kmem_cache *s,
void **object;
struct kmem_cache_cpu *c;
unsigned long flags;
+ unsigned int objsize;
local_irq_save(flags);
c = get_cpu_slab(s, smp_processor_id());
+ objsize = c->objsize;
if (unlikely(!c->freelist || !node_match(c, node)))
object = __slab_alloc(s, gfpflags, node, addr, c);
@@ -1643,7 +1645,7 @@ static __always_inline void *slab_alloc(struct kmem_cache *s,
local_irq_restore(flags);
if (unlikely((gfpflags & __GFP_ZERO) && object))
- memset(object, 0, c->objsize);
+ memset(object, 0, objsize);
return object;
}
next prev parent reply other threads:[~2008-07-10 20:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 11:59 Vegard Nossum
2008-07-10 12:12 ` Vegard Nossum
2008-07-10 12:50 ` Dmitry Adamushko
2008-07-10 13:04 ` Vegard Nossum
2008-07-10 13:17 ` Vegard Nossum
2008-07-10 13:33 ` Vegard Nossum
2008-07-10 13:43 ` Vegard Nossum
2008-07-10 14:03 ` Dmitry Adamushko
2008-07-10 14:16 ` Vegard Nossum
2008-07-10 15:06 ` Vegard Nossum
2008-07-10 19:49 ` Vegard Nossum
2008-07-10 20:16 ` Dmitry Adamushko [this message]
2008-07-11 5:49 ` Vegard Nossum
2008-07-11 9:02 ` Dmitry Adamushko
2008-07-11 11:04 ` Vegard Nossum
2008-07-11 11:46 ` Dmitry Adamushko
2008-07-11 17:51 ` Vegard Nossum
2008-07-11 18:00 ` Vegard Nossum
2008-07-11 23:42 ` Dmitry Adamushko
2008-07-10 20:20 ` Rafael J. Wysocki
2008-07-11 5:23 ` Vegard Nossum
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=b647ffbd0807101316o97fe6d4p5b2cbcda472f2ae1@mail.gmail.com \
--to=dmitry.adamushko@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=avi@qumranet.com \
--cc=clameter@sgi.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=ego@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=rusty@rustcorp.com.au \
--cc=vegard.nossum@gmail.com \
--cc=yanmin_zhang@linux.intel.com \
/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
Powered by JetHome