Messages in this thread | | | From | Andi Kleen <> | Subject | Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP | Date | Wed, 26 Oct 2005 17:50:44 +0200 |
| |
On Wednesday 26 October 2005 17:21, Jan Beulich wrote:
> Hmm, then this isn't really useful for a debugger. There ought to be a > chance to filter exceptions early (i.e. debugger accesses to non-mapped > memory or non-existing MSRs) and a chance to detect bad faults (note > that the kernel normal exception recovery mechanism may not be usable > here because for example page faults first try to service the fault > before scanning the fixup tables, but a debugger will normally not want > a page-in to happen behind its back). I thought the latter was what gets > reported as DIE_OOPS, while the former would be the filtering occasions > (and I actually took the "grossly misnamed" comment in asm/kdebug.h as > additional indication for that).
All you want is a hook early in GPF, right? I guess that should be ok. I can see that it's useful on x86-64 due to the non canonical address fault resulting in GPFs mess.
Just send a patch.
-Andi - 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/
| |