All of lore.kernel.org
 help / color / mirror / Atom feed
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;
 }

  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 v2.6.26-rc9: kernel BUG at kernel/sched.c:5858! 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 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.