From: Randy Dunlap <randy.dunlap@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
lkml <linux-kernel@vger.kernel.org>,
Jan Beulich <jbeulich@novell.com>, Ingo Molnar <mingo@elte.hu>,
Zachary Amsden <zach@vmware.com>
Subject: Re: crashme fault
Date: Sun, 16 Sep 2007 22:06:43 -0700 [thread overview]
Message-ID: <20070916220643.bea3e44f.randy.dunlap@oracle.com> (raw)
In-Reply-To: <alpine.LFD.0.999.0709161055070.16478@woody.linux-foundation.org>
On Sun, 16 Sep 2007 11:12:23 -0700 (PDT) Linus Torvalds wrote:
>
>
> On Sun, 16 Sep 2007, Linus Torvalds wrote:
> >
> > I'm really starting to suspect some early EM64T bug, and I also suspect
> > that it's harmless but that we should just do the trivial patch to say "if
> > the register state is in user mode, we don't care if the CPU says it was a
> > kernel access".
>
> Namely something like this..
>
> The basic idea is that it's pointless to test for "error_code & PF_USER"
> to decide whether we should oops or kill the process: the *real* issue is
> whether we *can* kill the process or not. And that depends not on whether
> the CPU claimed it was a user access or not, but on whether the register
> state we'd return to is user-mode or not!
>
> So anything that decides whether it should send a signal or do to the
> "no_context" Ooops path should use "user_mode_vm(regs)" (yeah, I realize
> that the "_vm" part is unnecessary on x86-64, but it doesn't hurt either,
> and all of the issues are the same on 32/64-bit) which tests the right
> thing.
>
> Now, normally the USER bit in the error code should be the exact same
> thing, except for
>
> - Some CPU bug (microcode issue, whatever) where some complex fault
> situation sets the wrong error code.
>
> - user space accesses that caused a system page fault (ie a page fault
> while handling another trap - possibly due to lazy page table setup
> and having the LDT or some other CPU data structure in vmalloc space)
>
> Now, the vmalloc space accesses should be handled separately anyway, so I
> really wonder if it's some subtle CPU bug (I can't reproduce any problems
> on my Core 2 Duo), but the point is that I think this patch really is
> conceptually a real fix regardless, even if it _shouldn't_ matter.
>
> Comments?
>
> Randy, this replaces the hacky patch I sent, but also shuts up about the
> odd thing you're hitting, so for testing your case further this may not be
> the right thing. However, it would be nice to hear whether this just makes
> "crashme" work properly for you without any side effects..
I'll test this overnight on 2.6.23-rc6-git2 since that was failing.
I haven't been able to reproduce the fault on 2.6.21 after several
hours of testing.
I'll also test a microcode update to see if it helps.
---
~Randy
next prev parent reply other threads:[~2007-09-17 5:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-13 5:21 crashme fault Randy Dunlap
2007-09-15 4:28 ` Linus Torvalds
2007-09-15 5:05 ` Randy Dunlap
2007-09-15 5:21 ` Randy Dunlap
2007-09-15 18:34 ` Andi Kleen
2007-09-15 18:40 ` Randy Dunlap
2007-09-15 19:44 ` Linus Torvalds
2007-09-15 19:53 ` Randy Dunlap
2007-09-15 22:15 ` Linus Torvalds
2007-09-15 22:47 ` Linus Torvalds
2007-09-15 23:47 ` Randy Dunlap
2007-09-16 0:34 ` Linus Torvalds
2007-09-16 16:40 ` Randy Dunlap
2007-09-16 17:14 ` Linus Torvalds
2007-09-16 18:12 ` Linus Torvalds
2007-09-17 5:06 ` Randy Dunlap [this message]
2007-09-17 5:28 ` Linus Torvalds
2007-09-17 14:29 ` Randy Dunlap
2007-09-17 14:53 ` Linus Torvalds
2007-09-17 20:05 ` Randy Dunlap
2007-09-16 18:28 ` Andi Kleen
2007-09-16 3:10 ` Andi Kleen
2007-09-16 15:53 ` Andrea Arcangeli
2007-09-16 16:17 ` Randy Dunlap
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=20070916220643.bea3e44f.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=andi@firstfloor.org \
--cc=jbeulich@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=zach@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox