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: 31+ 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:14 ` Antonino A. Daplas
2007-05-30 23:18 ` David Miller
2007-05-30 23:18 ` David Miller
2007-05-30 23:28 ` Antonino A. Daplas
2007-05-30 23:28 ` Antonino A. Daplas
2007-05-31 7:17 ` Geert Uytterhoeven
2007-05-31 7:17 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2007-05-31 9:04 ` Antonino A. Daplas
2007-05-31 9:04 ` [Linux-fbdev-devel] " 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 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.