linux-kernel - Re: v2.6.26-rc9: kernel BUG at kernel/sched.c:5858!

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: <19f34abd0807102249t6b2e9e97l97bc5b22cc7709ef@mail.gmail.com>
Date:	Fri, 11 Jul 2008 07:49:34 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Dmitry Adamushko" <dmitry.adamushko@...il.com>
Cc:	"Pekka Enberg" <penberg@...helsinki.fi>,
	Yanmin <yanmin_zhang@...ux.intel.com>,
	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>,
	"Gautham R Shenoy" <ego@...ibm.com>,
	"Heiko Carstens" <heiko.carstens@...ibm.com>, miaox@...fujitsu.com,
	"Lai Jiangshan" <laijs@...fujitsu.com>,
	"Avi Kivity" <avi@...ranet.com>, linux-kernel@...r.kernel.org
Subject: Re: v2.6.26-rc9: kernel BUG at kernel/sched.c:5858!

On Thu, Jul 10, 2008 at 10:16 PM, Dmitry Adamushko
<dmitry.adamushko@...il.com> wrote:
> 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?

Nice :-)

By the way, this also explains the heavy corruption I was seeing (NULL
pointers in lists detected by list debugging, etc.); SLUB was doing a
HUGE memset of 0 on arbitrary memory, i.e. the memset effectively
became:

    memset(object, 0, 0x1adadada);

..and in some of the cases, the machine didn't crash inside SLUB but
proceeded...

I guess I should reload and try the latest -git now :-)

Thanks!


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/