[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090914071631.GA24801@elte.hu>
Date: Mon, 14 Sep 2009 09:16:31 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Eric Paris <eparis@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>,
Jens Axboe <jens.axboe@...cle.com>
Cc: James Morris <jmorris@...ei.org>, Thomas Liu <tliu@...hat.com>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [origin tree SLAB corruption] BUG kmalloc-64: Poison overwritten,
INFO: Allocated in bdi_alloc_work+0x2b/0x100 age=175 cpu=1 pid=3514
* Eric Paris <eparis@...hat.com> wrote:
> On Sat, 2009-09-12 at 09:24 +0200, Ingo Molnar wrote:
> > James - i did not see a security pull request email from you in my
> > lkml folder so i created this new thread. -tip testing found the
> > easy crash below. It reverts cleanly so i went that easy route.
> >
> > At a really quick 10-seconds glance the crash happens because we
> > destroy the slab cache twice, if the sysctl is toggled twice?
>
> Something a lot worse than SELinux here. I added this exact code and
> got this warning. Something is wrong in the world of
> kmem_cache_destroy.....
-tip testing just triggered another type of SLAB problem (this time
not apparently related to the security subsystem):
BUG kmalloc-64: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xf498f6a0-0xf498f6a7. First byte 0x90 instead of 0x6b
INFO: Allocated in bdi_alloc_work+0x2b/0x100 age=175 cpu=1 pid=3514
INFO: Freed in bdi_work_free+0x45/0x60 age=9 cpu=1 pid=3509
INFO: Slab 0xc3257d84 objects=36 used=11 fp=0xf498f690 flags=0x400000c3
INFO: Object 0xf498f690 @offset=1680 fp=0xf498fe00
Bytes b4 0xf498f680: ab 0d 00 00 9c 27 ff ff 5a 5a 5a 5a 5a 5a 5a 5a «....'ÿÿZZZZZZZZ
Object 0xf498f690: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xf498f6a0: 90 f3 98 f4 60 3c 11 c1 6b 6b 6b 6b 6b 6b 6b 6b .ó.ô`<.Ákkkkkkkk
Object 0xf498f6b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object 0xf498f6c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk¥
Redzone 0xf498f6d0: bb bb bb bb »»»»
Padding 0xf498f6f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 3514, comm: sync Not tainted 2.6.31-tip-02343-gb432421-dirty #14071
Call Trace:
[<c10e5b29>] print_trailer+0xf9/0x170
[<c10e5c95>] check_bytes_and_report+0xf5/0x120
[<c10e7129>] check_object+0x1e9/0x230
[<c10e848d>] alloc_debug_processing+0xfd/0x1d0
[<c111394b>] ? bdi_alloc_work+0x2b/0x100
[<c10e8687>] __slab_alloc+0x127/0x330
[<c111394b>] ? bdi_alloc_work+0x2b/0x100
[<c111394b>] ? bdi_alloc_work+0x2b/0x100
[<c10e8a43>] kmem_cache_alloc+0x1b3/0x1d0
[<c111394b>] ? bdi_alloc_work+0x2b/0x100
[<c111394b>] ? bdi_alloc_work+0x2b/0x100
[<c11148a4>] ? bdi_writeback_all+0x34/0x190
[<c111394b>] bdi_alloc_work+0x2b/0x100
[<c194c6b2>] ? _spin_lock+0x72/0x90
[<c11148e2>] bdi_writeback_all+0x72/0x190
[<c107b3db>] ? mark_held_locks+0x6b/0xb0
[<c194ab75>] ? __mutex_unlock_slowpath+0xf5/0x160
[<c107b76c>] ? trace_hardirqs_on_caller+0x15c/0x1c0
[<c1114a48>] sync_inodes_sb+0x48/0x70
[<c1118b0b>] __sync_filesystem+0x7b/0x90
[<c1118c13>] sync_filesystems+0xf3/0x140
[<c1118cd7>] sys_sync+0x27/0x60
[<c100344b>] sysenter_do_call+0x12/0x36
FIX kmalloc-64: Restoring 0xf498f6a0-0xf498f6a7=0x6b
Now, this might be an extended arm of the security related slab
troubles. (which seem to have been cured by the revert i posted
though.)
This bug is not bisectable at all - it happened after 1000+
successful random bootups. The mainline base for
2.6.31-tip-02343-gb432421 is upstream commit 86d7101.
Full bootlog and config attached.
Ingo
View attachment "boot.log" of type "text/plain" (193016 bytes)
View attachment "config-Mon_Sep_14_08_54_02_CEST_2009.bad" of type "text/plain" (66586 bytes)
Powered by blists - more mailing lists