All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Zeno Davatz <zdavatz@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.31-rc1 crashes randomly on my Machine.
Date: Fri, 26 Jun 2009 08:39:19 +0100	[thread overview]
Message-ID: <20090626073919.GD8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20090626071520.GC8633@ZenIV.linux.org.uk>

On Fri, Jun 26, 2009 at 08:15:21AM +0100, Al Viro wrote:
> On Fri, Jun 26, 2009 at 08:56:52AM +0200, Zeno Davatz wrote:
> 
> > Jun 25 21:19:12 zenogentoo Code: 00 00 00 c7 47 20 00 00 00 00 c7 47
> > 24 00 00 00 00 c7 47 10 00 00 00 00 c7 47 14 00 00 00 00 c7 47 0c 00
> > 00 00 00 e9 27 ff ff ff <ff> 89 e5 57 56 53 83 ec 34 89 45 d0 89 55 cc
> > 89 4d c8 8b 70 6c
> > Jun 25 21:19:12 zenogentoo EIP: [<c10d1d35>] seq_read+0x0/0x3a5 SS:ESP
> > 0068:f4b01f44
> > Jun 25 21:19:12 zenogentoo CR2: 0000000053565be5
> > Jun 25 21:19:12 zenogentoo ---[ end trace 6254fef9dc80950b ]---
> > Jun 25 21:19:12 zenogentoo BUG: unable to handle kernel paging request
> > at 53565be5
> 
> Real cute...  Disassembly of that sucker:
> 	decl   0x535657e5(%ecx)
> which matches nicely the address in page fault.  However, that doesn't
> look even remotely plausible for a beginning of function.  OTOH,
> disassembly at one byte offset from that gives
> 	mov    %esp,%ebp
> 	push   %edi
> 	push   %esi
> 	push   %ebx
> which is exactly what you'd expect to see in such place.

Actually, it's not *quite* what you'd expect to see.  What's missing is
	push   %ebp
as the first instruction, preceding that stuff.  And it would take one
byte, so...

>  IOW, you've
> got an off-by-one - it had jumped at one byte before the actual entry
> point of seq_read().

... this is not an off-by-one at all.  The first byte of function code
got overwritten with 0xff.  Code before that doesn't seem to be mangled -
it's
	movl   $0x0,0x20(%edi)
	movl   $0x0,0x24(%edi)
	movl   $0x0,0x10(%edi)
	movl   $0x0,0x14(%edi)
	movl   $0x0,0xc(%edi)
	jmp    <a bit back>
which is at least not entirely implausible.  So it seems to be a memory
corruption in .text, which might or might not affect the directly
preceding bytes (0xe9 <signed 32bit int> is a relative jump, so there's
no way to tell whether this 0xff had been the only byte affected - it
would be preceded by 3 0xff coming from small negative integer anyway).

  reply	other threads:[~2009-06-26  7:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-26  6:56 2.6.31-rc1 crashes randomly on my Machine Zeno Davatz
2009-06-26  7:15 ` Al Viro
2009-06-26  7:39   ` Al Viro [this message]
2009-06-27 11:10     ` Zeno Davatz
2009-06-27 16:42       ` Al Viro
2009-06-29  6:35         ` Zeno Davatz

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=20090626073919.GD8633@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zdavatz@gmail.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.