Re: Is notify_die being overloaded?

[Keith Owens <kaos@sgi.com>]

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.
>
>Specifically, the following call notify_die when there are machine
>related events:
>ia64_mca_rendez_int_handler (DIE_MCA_RENDZVOUS_ENTER,
>	DIE_MCA_RENDZVOUS_PROCESS, DIE_MCA_RENDZVOUS_LEAVE)
>ia64_mca_handler (DIE_MCA_MONARCH_ENTER, DIE_MCA_MONARCH_PROCESS,
>	DIE_MCA_MONARCH_LEAVE)
>ia64_init_handler (DIE_INIT_ENTER,
>	DIE_INIT_{SLAVE|MONARCH}_{ENTER|PROCESS|LEAVE})
>ia64_mca_init (DIE_MCA_NEW_TIMEOUT)
>machine_restart (DIE_MACHINE_RESTART)
>machine_halt (DIE_MACHINE_HALT)
>die (DIE_OOPS)
>
>
>The following seem to be process related:
>ia64_bad_break (DIE_BREAK, DIE_FAULT)
>ia64_do_page_fault (DIE_PAGE_FAULT)
>
>
>Shouldn't these really be seperated into two seperate notifier chains?
>One for OS level die() type activity and another for process faults
>which a debugger et. al. would want to know about?

The only real problem is the page fault handler event.  All the other
calls to notify_die() are for rare events (MCA, INIT, restarts, halt,
oops) or for debugging events, none of which are performance critical.
DIE_PAGE_FAULT is only called because kprobes needs it, but that call
is on a performance critical path and it can significantly slow down
the rest of the system.

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.