Messages in this thread | | | From | Keith Owens <> | Subject | Re: Is notify_die being overloaded? | Date | Tue, 18 Apr 2006 10:23:52 +1000 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |