lkml.org 
[lkml]   [2017]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: BUG: unable to handle kernel paging request in __switch_to
On Thu, Dec 14, 2017 at 1:27 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Thu, Dec 14, 2017 at 11:28 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> I don't think that's the case. "int3" is entirely synchronous, and
>> doesn't have the same odd issues as a breakpoint trap (which honors RF
>> etc). It's literally just a one-byte shorthand for "int $3".
>
> The SDM says precisely the same thing about INT N, so, whichever way
> you dice it, int3 is a benign exception.

That just means that it doesn't double-fault when it takes the page fault.

Which we already know, because we see a page fault, not a double fault.

> 0xfffffffffffffff8 is *exactly* where the fault would be if the
> microcoded push of SS faulted if the IST contained zeros.

Yes, I suspect it's the stack that is buggered for some reason.

>> Plus I think the instruction that gets overwritten is just a 5-byte
>> nop isn't it? So it really shouldn't take a fault without the "int3"
>> overwriting.
>
> Unless it was being overwritten the other way and the oops hit while
> tracing was being turned *off*.

Doesn't really matter. The two forms of that instruction are "5-byte
nop" and "unconditional branch".

Neither of them will write to anything - the only page fault they
could take is for instruction fetch.

So it really must be the "int3" that fails. Unless we're looking at
some odd CPU errata, which sounds very very unlikely.

Linus

\
 
 \ /
  Last update: 2017-12-14 22:39    [W:0.086 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site