This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Per an AR from the 4/20/05 meeting, here is a patch that runs kprobes' pre_handlers on a separate kprobes_stack. This code is i386-specific and is based on the CONFIG_4KSTACKS stack-switch code in do_IRQ(). This patch is against Linux 2.6.12-rc4 + Hien's i386 return-probes patch. (2.6.12-rc4 contains Ananth's multi-probes patch.) Effect on Return Probes kretprobe handlers will run on the kprobes stack because they are called by trampoline_p.pre_handler. Effect on Jprobes jprobe handlers will not run on the kprobes stack. (The whole point of jprobes is that the handler is presented with exactly the stack that is presented to the probed function.) Testing I have tested with a combination of kprobes, jprobes, and return probes, including a probe set in an interrupt handler. I have not done severe stress testing or SMP testing. I'll post this patch and accompanying test modules to CVS. I haven't tested this with REGPARM configured, but the register usage is such that it should work with or without REGPARM. Limitations/TODO A similar function could be copied-and-pasted for post_handlers. I thought about trying to support both pre_ and post_handlers with a single function, but they have different signatures. I haven't figured out kprobes fault handling well enough to understand the implications of this separate stack. Once Ananth's SMP scalability patch is factored in, this kprobes_stack patch will need to be adjusted to use per-CPU stacks, as in the CONFIG_4KSTACKS code. Comments/advice welcome. Jim
Attachment:
kprobes_stack.patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |