As mentioned in Documentation/kprobes.txt (in 2.6.13-rc* and beyond), it's a bad
idea to install a probe in the code that implements Kprobes -- e.g.,
*/kprobes.c. A patch set by Prasanna Panchamukhi (see LKML 7/7/05) teaches
Kprobes to reject probes in most such code.
As we learn of other areas of the kernel where setting a probe could lead to
problems, we need to document them.
I vote for do_IRQ for starters. We are currently unable to handle kprobes on
routines that execute as a result of asynchronous (read hardware) interrupts.
Problems have been seen on x86_64 and ppc64 as of now.
Fixing this would require disabling of interrupts upon entry in the traps code
(much before kprobes get notified), and this is likely to generate debate and
take time to stabilize - we'll be fiddling with very touchy regions of arch code
bug #1828 has a patch committed. The output of this bug's efforts can, for the
moment, go into the new "blacklisted_p" function in tapsets.cxx.
Further discussion on this topic can be found on the SystemTap mailing list.
See the thread rooted at:
The various blacklists fulfill this job.
Future blacklist-deserving probes can get their own bugs.