Bug 1235 - Document areas of kernel that aren't safe to probe
Summary: Document areas of kernel that aren't safe to probe
Alias: None
Product: systemtap
Classification: Unclassified
Component: kprobes (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Jim Keniston
Depends on:
Blocks: 1828
  Show dependency treegraph
Reported: 2005-08-24 21:37 UTC by Jim Keniston
Modified: 2008-05-28 16:02 UTC (History)
3 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Jim Keniston 2005-08-24 21:37:45 UTC
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.
Comment 1 Ananth N Mavinakayanahalli 2005-08-26 15:58:28 UTC
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
Comment 2 Frank Ch. Eigler 2005-11-07 22:01:27 UTC
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.
Comment 3 Jim Keniston 2006-11-15 23:59:54 UTC
Further discussion on this topic can be found on the SystemTap mailing list. 
See the thread rooted at:
Comment 4 Frank Ch. Eigler 2008-05-28 16:02:46 UTC
The various blacklists fulfill this job.
Future blacklist-deserving probes can get their own bugs.