This is the mail archive of the
mailing list for the systemtap project.
[Bug uprobes/5079] runtime/uprobes: stap module exit w/ outstanding uretprobe_instances
- From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 2 Oct 2007 18:31:09 -0000
- Subject: [Bug uprobes/5079] runtime/uprobes: stap module exit w/ outstanding uretprobe_instances
- References: <email@example.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jkenisto at us dot ibm dot com 2007-10-02 18:31 -------
Here's a proposed design for modifying stap to optionally build
and use a uprobes module whose source resides in runtime/uprobes.
Currently, runtime/uprobes contains code that is included
directly into the stap-generated module. This suffers from
problems, as reported in this bugzilla. It will be modified
to be built as a kernel module that staprun can insert, as
needed, before inserting the stap-generated module.
If stap emits calls to the uprobes API, it will also attempt to
build uprobes as a module, using the source and (new) Makefile
in runtime/uprobes. Stap will also pass the -u ("uprobes") flag
To account for the possibility of uprobes being part of the kernel
build (either as a module or as a built-in component), stap will
generate code that looks something like:
#if defined(CONFIG_UPROBES) || defined(CONFIG_UPROBES_MODULE)
When passed the -u flag, staprun will check to see whether (say)
unregister_uprobe already shows up in /proc/kallsyms. If it doesn't,
staprun will try the following before loading the SystemTap-generated
1. modprobe uprobes
2. Load uprobes.ko from runtime/uprobes.
Seems like we have to do #1 first because of the way the above
#includes work. If the user wants to use the stap-runtime version
of uprobes.ko instead of the version in /lib/modules, then I
guess he/she should copy the stap-runtime version into
- Should we avoid the make if (say) unregister_uprobe already shows
up in /proc/kallsyms? What would be the implications for a "stap now,
staprun later" scenario?
- Should we avoid using /lib/modules/.../uprobes.ko, and instead
use only the stap runtime version? If so, we'd take the
"defined(CONFIG_UPROBES_MODULE)" clause out of the above code;
and we'd skip the modprobe.
What |Removed |Added
CC| |dsmith at redhat dot com,
| |hunt at redhat dot com, fche
| |at redhat dot com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.