[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Jul 2021 10:36:28 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
Daniel Xu <dxu@...uu.xyz>, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, kuba@...nel.org, mingo@...hat.com,
ast@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>, kernel-team@...com, yhs@...com,
linux-ia64@...r.kernel.org,
Abhishek Sagar <sagar.abhishek@...il.com>,
Andrii Nakryiko <andrii.nakryiko@...il.com>,
wuqiang.matt@...edance.com
Subject: Re: [PATCH -tip v8 11/13] x86/unwind: Recover kretprobe trampoline
entry
On Wed, Jul 07, 2021 at 10:20:41AM +0200, Peter Zijlstra wrote:
> > > Steve, can you clarify the ftrace side here? Afaict return_to_handler()
> > > is similarly affected.
> >
> > I'm not exactly sure what the issue is. As Masami stated, kretprobe
> > uses a ret to return to the calling function, but ftrace uses a jmp.
>
> I'll have to re-read the ftrace bits, but from the top of my head you
> cannot do an indirect jump and preserve all registers at the same time,
> so a return stub must use jump from stack aka. ret.
Hmm... there's callee clobbered regs ofcourse, which don't need to be
preserved. And that's exactly what ftrace seems to be doing, and I don't
think there's any reason why kretprobe cannot do the same. Lemme try.
Powered by blists - more mailing lists