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
next prev 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