On Sun, 16 Sep 2007 11:12:23 -0700 (PDT) Linus Torvalds wrote:

quoted text
> 
> 
> 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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/