Messages in this thread | | | Date | Fri, 5 Mar 2021 11:16:45 -0800 | From | Daniel Xu <> | Subject | Re: [PATCH -tip 0/5] kprobes: Fix stacktrace in kretprobes |
| |
Hi Masami,
On Sat, Mar 06, 2021 at 12:38:57AM +0900, Masami Hiramatsu wrote: > Hello, > > Here is a series of patches for kprobes and stacktracer to fix the kretprobe > entries in the kernel stack. This was reported by Daniel Xu. I thought that > was in the bpftrace, but it is actually more generic issue. > So I decided to fix the issue in arch independent part. > > While fixing the issue, I found a bug in ia64 related to kretprobe, which is > fixed by [1/5]. [2/5] and [3/5] is a kind of cleanup before fixing the main > issue. [4/5] is the patch to fix the stacktrace, which involves kretprobe > internal change. And [5/5] removing the stacktrace kretprobe fixup code in > ftrace. > > Daniel, can you also check that this fixes your issue too? I hope it is.
Unfortunately, this patch series does not fix the issue I reported.
I think the reason your tests work is because you're using ftrace and the ORC unwinder is aware of ftrace trampolines (see arch/x86/kernel/unwind_orc.c:orc_ftrace_find).
bpftrace kprobes go through perf event subsystem (ie not ftrace) so naturally orc_ftrace_find() does not find an associated trampoline. ORC unwinding fails in this case because arch/x86/kernel/kprobes/core.c:trampoline_handler sets
regs->ip = (unsigned long)&kretprobe_trampoline;
and `kretprobe_trampoline` is marked
STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
so it doesn't have a valid ORC entry. Thus, ORC immediately bails when trying to unwind past the first frame.
The only way I can think of to fix this issue is to make the ORC unwinder aware of kretprobe (ie the patch I sent earlier). I'm hoping you have another idea if my patch isn't acceptable.
Thanks, Daniel
| |