DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

[Jan Beulich]

What is the reason for notify_die(DIE_GPF, ...) to be run late in the GP
fault handler (on both i386 and x86-64), while for other exceptions it
gets run first thing (as I would have expected for all exceptions)?

Thanks, Jan

Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

[Andi Kleen]

On Wednesday 26 October 2005 16:44, Jan Beulich wrote:
> What is the reason for notify_die(DIE_GPF, ...) to be run late in the GP
> fault handler (on both i386 and x86-64), while for other exceptions it
> gets run first thing (as I would have expected for all exceptions)?

"die"s as the name says are normally only supposed to run when the
error is determined to be an illegal kernel fault.  Page fault
got an exception to that to make kprobes work. For the others
it is mostly only because there is no good way to check
for illegal kernel faults first.

-Andi

Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

[Jan Beulich]

>>> Andi Kleen <ak@suse.de> 26.10.05 17:01:52 >>>
>On Wednesday 26 October 2005 16:44, Jan Beulich wrote:
>> What is the reason for notify_die(DIE_GPF, ...) to be run late in
the GP
>> fault handler (on both i386 and x86-64), while for other exceptions
it
>> gets run first thing (as I would have expected for all exceptions)?
>
>"die"s as the name says are normally only supposed to run when the
>error is determined to be an illegal kernel fault.  Page fault
>got an exception to that to make kprobes work. For the others
>it is mostly only because there is no good way to check
>for illegal kernel faults first.

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).

Jan

Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

[Andi Kleen]

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

Re: DIE_GPF vs. DIE_PAGE_FAULT/DIE_TRAP

[Jan Beulich]

>>> Andi Kleen <ak@suse.de> 26.10.05 17:50:44 >>>
>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. 

Yes. Now, would you see this to replace the current one, or in addition
to it?

Jan