Messages in this thread | | | From | Keith Owens <> | Subject | Re: Is notify_die being overloaded? | Date | Mon, 17 Apr 2006 17:52:10 +1000 |
| |
Robin Holt (on Sat, 15 Apr 2006 05:43:56 -0500) wrote: >On Sat, Apr 15, 2006 at 04:19:55PM +1000, Keith Owens wrote: >> Robin Holt (on Thu, 13 Apr 2006 14:46:44 -0500) wrote: >> >notify_die seems to be called to indicate the machine is going down as >> >well as there are trapped events for the process. >... >> The only real problem is the page fault handler event. All the other >... >> >> 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. > >I realize the page fault handler is the only performance critical event, >but don't all the debugging events _REALLY_ deserve a seperate call chain? >They are _completely_ seperate and isolated events. One is a minor event >which a small number of other userland processes are concerned with. >The other is indicating the machine is about stop running and is only >relevant to critical system infrastructure.
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.
[*] It does not help that IA64 break.b <n> does not store the value of <n> in cr.iim. All break.b values look like break.b 0. There used to be code in traps.c to detect this and extract the value of break.b, but a kprobes patch removed that code.
- 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/
| |