From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [patch] x86: optimise page fault entry
Date: Tue, 20 Jan 2009 11:09:46 +0100 [thread overview]
Message-ID: <20090120100946.GA7886@elte.hu> (raw)
In-Reply-To: <20090120032426.GE16304@wotan.suse.de>
* Nick Piggin <npiggin@suse.de> wrote:
> Hi,
>
> Sorry for the delay with this. The kernel ended up unbootable for me
> when I last dusted off the patch, so I couldn't test it and then
> promptly got sidetracked with other things.
>
> Anyway, this one is tested with a boot, some basic segfault sigbus etc
> tests, and passes various of the mmap and mprotect etc. ltp tests.
>
> Ingo, would you merge this into the x86 tree, please? (unless Linus has
> any objections to this version)
-tip testing found a 32-bit boot regression, caused by this patch. The
bootup hangs early, during the WP write-test check:
[ 0.004000] .data : 0xc0691f05 - 0xc09c746c (3285 kB)
[ 0.004000] .text : 0xc0100000 - 0xc0691f05 (5703 kB)
[ 0.004000] Checking if this processor honours the WP bit even in supervisor mode...
i've excluded x86/mm from tip/master for now, you can find the broken tree
in the tip/tip.x86.mm.broken [v2.6.29-rc2-1069-g583f1b9] branch that i
just pushed out:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tip.x86.mm.broken
Also, a patch structure sidenote, the diffstat is rather large:
arch/x86/mm/fault.c | 436 ++++++++++++++++++++++++++++++---------------------
1 files changed, 255 insertions(+), 181 deletions(-)
this shuffles 300 lines of highly critical x86 code around - which makes
me nervous. A finegrained, bisectable series would be far more debuggable.
Had we such a lineup i could have auto-bisected it for you already - while
now you have to see which bit of the ~500 lines of code flux broke the
32-bit WP test.
This hang might be easy to find and fix (the WP detect logic is simple),
but other failure modes might be less debuggable and this codepath deals
with a lot of obscure details like CPU errata. So it would be really nice
to have a finegrained splitup of this patch.
Three separate testsystems triggered this hang so it should be readily
reproducible.
Thanks,
Ingo
next prev parent reply other threads:[~2009-01-20 10:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-20 3:24 [patch] x86: optimise page fault entry Nick Piggin
2009-01-20 5:11 ` Linus Torvalds
2009-01-20 8:25 ` Ingo Molnar
2009-01-20 10:09 ` Ingo Molnar [this message]
2009-01-20 12:07 ` Nick Piggin
2009-01-20 12:18 ` Ingo Molnar
2009-01-21 19:45 ` Johannes Weiner
2009-01-21 20:37 ` Ingo Molnar
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=20090120100946.GA7886@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.org \
/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