From: Andrew Morton <akpm@linux-foundation.org>
To: Tero Roponen <teanropo@jyu.fi>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: tty-related oops in latest kernel(s)?
Date: Wed, 30 May 2007 08:39:53 -0700 [thread overview]
Message-ID: <20070530083953.9909bcef.akpm@linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0705301458400.4634@jalava.cc.jyu.fi>
On Wed, 30 May 2007 15:02:49 +0300 (EEST) Tero Roponen <teanropo@jyu.fi> wrote:
> On Wed, 30 May 2007, Pekka Enberg wrote:
>
> > On 5/30/07, Tero Roponen <teanropo@jyu.fi> wrote:
> > > Hmmm, I just found something interesting. In 2.6.21.3 the /sbin/init
> > > gets corrupted when I watch the video!
> > >
> > > $ cp /sbin/init init.before
> > > $ mplayer kiwi.flv
> > > $ cp /sbin/init init.after
> > >
> > > The sha1sums are here:
> > >
> > > 52c8d643057619cbe137b8e69d4709ce3bdd832d init.after
> > > 8efc7864a5b535a9e336fa82e9d7f112f3d956c1 init.before
> > >
> > > It seems that something corrupts memory somewhere...
> >
> > To debug this a bit further:
> >
> > $ od -a -t x1 -v init.after > init.after.dump
> > $ od -a -t x1 -v init.before > init.before.dump
> > $ diff -u init.before.dump init.after.dump | less
> >
> > -0011340 nul nul nul e9 f0 fe ff ff ff % < soh enq bs h 80
> > - 00 00 00 e9 f0 fe ff ff ff 25 3c 01 05 08 68 80
> > +0010000 y ack nul nul y ack nul nul y ack nul nul y ack nul nul
> > + 79 06 00 00 79 06 00 00 79 06 00 00 79 06 00 00
> > +0010020 y ack nul nul y ack nul nul y ack nul nul y ack nul nul
> > + 79 06 00 00 79 06 00 00 79 06 00 00 79 06 00 00
> > +0011340 y ack nul nul y ack nul nul ff % < soh enq bs h 80
> > + 79 06 00 00 79 06 00 00 ff 25 3c 01 05 08 68 80
> >
> > The file at offset 0010000 - 0011348 is overwritten with the byte
> > pattern 79 06 00 00.
> >
> > Do you see anything in the logs or is this a silent corruption? Did
> > you see this corruption with 2.6.19 or 2.6.22-rc3?
> >
>
> I recompiled 2.6.22-rc3 and booted it with slub_debug. Now I can't oops
> the kernel, but ./slab_info -v gives me a warning:
>
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> neofb: no support for 32bpp
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1024x768) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1152x864) larger than the LCD panel (800x600)
> Mode (1024x1024) larger than the LCD panel (800x600)
> Mode (1024x1024) larger than the LCD panel (800x600)
> Mode (1024x1024) larger than the LCD panel (800x600)
> Mode (1024x1024) larger than the LCD panel (800x600)
> Mode (1280x1024) larger than the LCD panel (800x600)
> Mode (1280x1024) larger than the LCD panel (800x600)
> Mode (1280x1024) larger than the LCD panel (800x600)
> Mode (1280x1024) larger than the LCD panel (800x600)
> *** SLUB kmalloc-1024: Redzone Active@0xc10be860 slab 0xc10217c0
> offset=2144 flags=0x80004082 inuse=7 freelist=0x00000000
> Bytes b4 0xc10be850: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ
> Object 0xc10be860: 00 00 00 00 00 20 00 00 20 03 00 00 58 02 00 00 ............X...
> Object 0xc10be870: 20 03 00 00 58 02 00 00 00 00 00 00 00 00 00 00 ....X...........
> Object 0xc10be880: 10 00 00 00 00 00 00 00 0b 00 00 00 05 00 00 00 ................
> Object 0xc10be890: 00 00 00 00 05 00 00 00 06 00 00 00 00 00 00 00 ................
> Object 0xc10be8a0: 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 ................
> Object 0xc10be8b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> Object 0xc10be8c0: ff ff ff ff ff ff ff ff 00 00 00 00 a8 61 00 00 ÿÿÿÿÿÿÿÿ....¨a..
> Object 0xc10be8d0: 58 00 00 00 28 00 00 00 17 00 00 00 01 00 00 00 X...(...........
> Redzone 0xc10bec60: 4d 6b 00 00 Mk..
> FreePointer 0xc10bec64 -> 0x00006b4d
> Last alloc: 0x6b4d jiffies_ago=4294923792 cpu=27469 pid=27469
> Last free : 0x6b4d jiffies_ago=4294923792 cpu=27469 pid=27469
> Filler 0xc10bec88: 4d 6b 00 00 4d 6b 00 00 Mk..Mk..
> [<c013f717>] check_object+0x64/0x23d
> [<c0141371>] validate_slab+0xff/0x12a
> [<c01413aa>] validate_slab_slab+0xe/0x51
> [<c0141488>] validate_store+0x9b/0xe8
> [<c01343d1>] __handle_mm_fault+0x370/0x68b
> [<c01413ed>] validate_store+0x0/0xe8
> [<c013eaa6>] slab_attr_store+0x1e/0x22
> [<c016e470>] sysfs_write_file+0xad/0xd6
> [<c016e3c3>] sysfs_write_file+0x0/0xd6
> [<c0143341>] vfs_write+0x8a/0x10c
> [<c01437d7>] sys_write+0x41/0x67
> [<c01022c2>] sysenter_past_esp+0x5f/0x85
> =======================
> @@@ SLUB kmalloc-1024: Restoring redzone (0xcc) from 0xc10bec60-0xc10bec63
>
So something did an overwrite of a 1024-byte kmalloc. Unfortunately that
overwrite seems to have trashed our last-alloc info, so we don't know who
allocated that memory. Darn.
Does the problem go away if you disable CONFIG_SLUB and enable CONFIG_SLAB?
next prev parent reply other threads:[~2007-05-30 15:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-27 9:06 tty-related oops in latest kernel(s)? Tero Roponen
2007-05-28 7:22 ` Pekka Enberg
2007-05-28 7:47 ` Pekka Enberg
2007-05-28 8:08 ` Tero Roponen
2007-05-28 9:34 ` Pekka Enberg
2007-05-29 16:04 ` Tero Roponen
2007-05-29 18:57 ` Pekka Enberg
2007-05-30 3:43 ` Tero Roponen
2007-05-30 3:57 ` Tero Roponen
2007-05-30 5:54 ` Pekka Enberg
2007-05-30 5:59 ` Pekka Enberg
2007-05-30 6:00 ` Tero Roponen
2007-05-30 12:02 ` Tero Roponen
2007-05-30 15:39 ` Andrew Morton [this message]
2007-05-30 16:01 ` Tero Roponen
2007-05-30 16:09 ` Andrew Morton
2007-05-30 18:04 ` Alexey Dobriyan
2007-05-30 23:14 ` Antonino A. Daplas
2007-05-30 23:18 ` David Miller
2007-05-30 23:28 ` Antonino A. Daplas
2007-05-31 7:17 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2007-05-31 9:04 ` Antonino A. Daplas
2007-05-30 18:13 ` Pekka Enberg
2007-05-30 18:27 ` Tero Roponen
2007-05-30 22:14 ` Antonino A. Daplas
2007-05-30 23:17 ` Antonino A. Daplas
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=20070530083953.9909bcef.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=teanropo@jyu.fi \
/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