public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-ext4@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: kerneloops.org: 2.6.26-rc possible regression in ext3
Date: Wed, 18 Jun 2008 23:14:12 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0806182302340.2907@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0806182242390.2907@woody.linux-foundation.org>



On Wed, 18 Jun 2008, Linus Torvalds wrote:
> 
> One thing I note is that all the oopses seem to be i686 - are there that 
> few x86-64 fc10 users (I'd have assumed that 64-bit is starting to be the 
> norm for people who live on the edge, but perhaps I'm just out of touch)? 
> 
> Or could this perhaps be an indication that it is specific to i686 some 
> way (eg a compiler issue?)

The oops code is odd:

  27:	8d 4c 18 fe          	lea    0xfffffffe(%eax,%ebx,1),%ecx
  2b:*	8b 19                	mov    (%ecx),%ebx     <-- trapping instruction
  2d:	83 e9 08             	sub    $0x8,%ecx
  30:	89 d8                	mov    %ebx,%eax
  32:	66 d1 e8             	shr    %ax
  35:	0f b7 c0             	movzwl %ax,%eax

and that "lea" is doing an address computation of "eax+2*ebx-2". Which 
does *not* look like an address to a 32-bit entity, but to a 16-bit one. 
Yeah, it's not conclusive, but it is suggestive.

And the 16-bit "shr+movzwl" further strengthens the case that it is 
actually working on a 16-bit entity. The trapping instruction _should_ 
possibly have been a "movzwl (%ecx),%ebx" to begin with.

But it did a 32-bit load, and in this case it looks as if the 16-bit load 
would have been correct! The value of ECX in this example was

	ECX: dc384ffe

ie it was indeed a two-byte aligned thing at the end of the page, and if 
the load had been a 16-bit load (like the data seems to be), it would 
never have oopsed! The page fault seems to be due to DEBUG_PAGEALLOC and 
the next page being unmapped because it's not allocated.

I only looked closer at one particular oops (25906, in case anybody 
cares), but at least judging from that particular one I would indeed 
suspect a compiler bug.

Of course, the main reason I say that is that none of the ext3 or VFS 
changes look even _remotely_ relevant to any of this. They really don't 
look like they could possibly matter for "do_split()" unless there is 
something really odd going on.

			Linus

  parent reply	other threads:[~2008-06-19  6:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19  5:34 kerneloops.org: 2.6.26-rc possible regression in ext3 Arjan van de Ven
2008-06-19  6:01 ` Linus Torvalds
2008-06-19  6:09   ` Arjan van de Ven
2008-06-19  6:14   ` Linus Torvalds [this message]
2008-06-19  6:40     ` Linus Torvalds
2008-06-20 15:34   ` Bill Nottingham
  -- strict thread matches above, loose matches on Subject: below --
2008-06-19  5:36 Arjan van de Ven
2008-06-19  5:42 ` Dave Airlie
2008-06-19  5:48   ` Arjan van de Ven
2008-06-19  6:42   ` Linus Torvalds
2008-06-19  7:09     ` Arjan van de Ven
2008-06-19  8:11   ` Adrian Bunk
2008-06-19  8:32     ` Mikael Pettersson
2008-06-19 10:49       ` Adrian Bunk
2008-06-19 13:40     ` Arjan van de Ven
2008-06-19 15:10       ` Adrian Bunk
2008-06-19 15:18         ` Arjan van de Ven
2008-06-19 15:25           ` Adrian Bunk
2008-06-19 15:27             ` Arjan van de Ven
2008-06-19 15:43               ` Adrian Bunk
2008-06-19 14:00 ` Eric Sandeen
2008-06-19 14:07   ` Arjan van de Ven
2008-06-19 14:17     ` Eric Sandeen

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=alpine.LFD.1.10.0806182302340.2907@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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