On 2018-11-02, Masami Hiramatsu mhiramat@kernel.org wrote:
Please split the test case as an independent patch.
Will do. Should the Documentation/ change also be a separate patch?
new file mode 100644 index 000000000000..03146c6a1a3c --- /dev/null +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_stacktrace.tc @@ -0,0 +1,25 @@ +#!/bin/sh +# SPDX-License-Identifier: GPL-2.0+ +# description: Kretprobe dynamic event with a stacktrace
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+echo 0 > events/enable +echo 1 > options/stacktrace
+echo 'r:teststackprobe sched_fork $retval' > kprobe_events +grep teststackprobe kprobe_events +test -d events/kprobes/teststackprobe
Hmm, what happen if we have 2 or more kretprobes on same stack? It seems you just save stack in pre_handler, but that stack can already includes another kretprobe's trampline address...
Yeah, you're quite right...
My first instinct was to do something awful like iterate over the set of "kretprobe_instance"s with ->task == current, and then correct kretprobe_trampoline entries using ->ret_addr. (I think this would be correct because each task can only be in one context at once, and in order to get to a particular kretprobe all of your caller kretprobes were inserted before you and any sibling or later kretprobe_instances will have been removed. But I might be insanely wrong on this front.)
However (as I noted in the other thread), there is a problem where kretprobe_trampoline actually stops the unwinder in its tracks and thus you only get the first kretprobe_trampoline. This is something I'm going to look into some more (despite not having made progress on it last time) since now it's something that actually needs to be fixed (and as I mentioned in the other thread, show_stack() actually works on x86 in this context unlike the other stack_trace users).