public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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