This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug kprobes/2068] New: return probe on __switch_to triggers BUG_ON
- From: "jkenisto at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 19 Dec 2005 19:53:13 -0000
- Subject: [Bug kprobes/2068] New: return probe on __switch_to triggers BUG_ON
- Reply-to: sourceware-bugzilla at sourceware dot org
Josh Stone reported a failure as follows:
-----
...
'kernel.function("__switch_to").return'.
This one is a problem with kretprobes only, as all of my other probes in
__switch_to behaved just fine, even in the middle of the function.
Running this gave "Kernel BUG at kprobes:449" (the full dump is included
below). The line mentioned is in trampoline_probe_handler:
BUG_ON(!orig_ret_address || (orig_ret_address ==
trampoline_address));
-----
The problem is probably that kretprobe_instance objects are hashed by the
current task pointer. Upon entry to __switch_to(), the object is placed on the
list for the "prev" task, but upon return it's sought on the list for the "next"
task.
If this indeed the problem, then:
1. Return probes on __switch_to should be blacklisted in the SystemTap
translator and kprobes unless and until a fix is found.
2. A fix in kprobes would presumably require kprobes to notice (either at
registration time or at function entry) that we're probing __switch_to(). Upon
function entry, we'd have to invoke architecture-specific (and potentially
version-dependent) code to grab the next-task pointer out of the arg list and
hash on that.
By the way, context_switch() should NOT be a problem, because it's inline and
kprobes doesn't support return probes on inline functions.
--
Summary: return probe on __switch_to triggers BUG_ON
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P1
Component: kprobes
AssignedTo: systemtap at sources dot redhat dot com
ReportedBy: jkenisto at us dot ibm dot com
http://sourceware.org/bugzilla/show_bug.cgi?id=2068
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.