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 there.
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: http://sourceware.org/ml/systemtap/2006-q3/msg00574.html
The various blacklists fulfill this job. Future blacklist-deserving probes can get their own bugs.