On Fri, May 24, 2019 at 10:53:19AM +0200, Peter Zijlstra wrote: > > 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
Right now, ftrace has a special hook in the ORC unwinder (orc_ftrace_find). It would be great if we could get rid of that in favor of the "always use frame pointers" approach. I'll hold off on doing the kpatch/kprobe trampoline conversions in my patches since it would conflict with yours. Though, hm, because of pt_regs I guess ORC would need to be able to decode an encoded frame pointer? I was hoping we could leave those encoded frame pointers behind in CONFIG_FRAME_POINTER-land forever... Here are my latest BPF unwinder patches in case anybody wants a sneak peek: https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=bpf-orc-fix -- Josh
