[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190524085319.GE2589@hirez.programming.kicks-ass.net>
Date: Fri, 24 May 2019 10:53:19 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Kairui Song <kasong@...hat.com>, Alexei Starovoitov <ast@...com>,
Song Liu <songliubraving@...com>,
lkml <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: Getting empty callchain from perf_callchain_kernel()
On Thu, May 23, 2019 at 10:24:13AM -0500, Josh Poimboeuf wrote:
> Here's the latest version which should fix it in all cases (based on
> tip/master):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/commit/?h=bpf-orc-fix
That patch suffers an inconsitency, the comment states:
'if they have "jump_table" in the name'
while the actual code implements:
'if the name starts with "jump_table"'
Other than that, I suppose that works just fine ;-)
> There's no need to put special cases in the FP unwinder when we can
> instead just fix the frame pointer usage in the JIT code.
>
> For ORC, I'm thinking we may be able to just require that all generated
> code (BPF and others) always use frame pointers. Then when ORC doesn't
> recognize a code address, it could try using the frame pointer as a
> fallback.
Yes, this seems like a sensible approach. We'd also have to audit the
ftrace and kprobe trampolines, IIRC they only do framepointer setup for
CONFIG_FRAME_POINTER currently, which should be easy to fix (after the
patches I have to fix the FP generation in the first place:
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=x86/wip
)
Powered by blists - more mailing lists