Summary: | Document areas of kernel that aren't safe to probe | ||
---|---|---|---|
Product: | systemtap | Reporter: | Jim Keniston <jkenisto> |
Component: | kprobes | Assignee: | Jim Keniston <jkenisto> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | amavin, anil.s.keshavamurthy, prasanna |
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | |||
Bug Blocks: | 1828 |
Description
Jim Keniston
2005-08-24 21:37:45 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 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. |