[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0709151508590.16478@woody.linux-foundation.org>
Date: Sat, 15 Sep 2007 15:15:50 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Randy Dunlap <randy.dunlap@...cle.com>
cc: Andi Kleen <andi@...stfloor.org>,
lkml <linux-kernel@...r.kernel.org>, Andi Kleen <ak@...e.de>
Subject: Re: crashme fault
On Sat, 15 Sep 2007, Linus Torvalds wrote:
>
> Here's a really *stupid* patch (and untested too, btw) to see if it gets
> easier to debug when you don't oops, just print the register state
> instead.
Side note - while thinking about this, I'm wondering whether maybe that
"stupid" patch might not actually be the right thing to do.
The fact is, the "user access" bit in the error code is in many ways a
totally *different* issue than the "user_mode(regs)" test. We may end up
having a system page fault for some action that was initiated by user
space: eg taking a page fault on a segment load. And it may well be marked
as a "system access" in the error code, even though the instruction that
triggered it was all user mode, and even though we could just terminate
the program rather than oops.
That said, since the kernel isn't paging itself out, user mode generally
should not be able to generate those kinds of system access page faults.
Our segment tables should all be in core, and so I would still in
*practice* always expect the register state and the error code to match in
the "usermode'ness".
So regardless of whether we want to trust "user_mode(regs)" more than
"error_code & PF_USER", it would definitely be very interesting if you can
give a good "this is where it started happening".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists