Re: Is notify_die being overloaded?

[Keith Owens]

Robin Holt (on Mon, 17 Apr 2006 06:25:52 -0500) wrote:
>On Mon, Apr 17, 2006 at 05:51:44AM -0500, Robin Holt wrote:
>> On Mon, Apr 17, 2006 at 05:52:10PM +1000, Keith Owens wrote:
>> > Robin Holt (on Sat, 15 Apr 2006 05:43:56 -0500) wrote:
>...
>> > Unfortunately the ebents are ambiguous.  On IA64 BUG() maps to break 0,
>> > but break 0 is also used for debugging[*].  Which makes it awkward to
>> > differentiate between a kernel error and a debug event, we have to
>> > first ask the debuggers if the event if for them then, if the debuggers
>> > do not want the event, drop into the die_if_kernel event.
>> 
>> I think this still would argue for a notify_debugger() sort of callout
>> which would read something like:
>
>I finally think I understand your point.  You are saying that kdb would
>have to register for the notify_debugger() chain and would therefore
>get in the way of handle_page_fault().  What about changing notify_die()
>callout in handle_page_fault() into a notify_page_fault().  That actually
>feels a lot better now that you got me to think about it.

I thought that is what I said in my original response, "kprobes should
be using its own notify chain to trap page faults, and the handler for
that chain should be optimized away when CONFIG_KPROBES=n or there are
no active probes".

Even the overhead of calling into a notify_page_fault() routine just to
do nothing adds a measurable overhead to the page fault handler
(according to Jack Steiner).  Since kprobes is the only code that needs
a callback on a page fault, it is up to kprobes to minimize the impact
of that callback on the normal processing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/