[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200401113911.21b67c0a@gandalf.local.home>
Date: Wed, 1 Apr 2020 11:39:11 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>, tglx@...utronix.de,
linux-kernel@...r.kernel.org, x86@...nel.org, mhiramat@...nel.org,
mbenes@...e.cz
Subject: Re: [PATCH v2] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET
On Wed, 1 Apr 2020 09:39:16 -0500
Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> > > > + if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) {
> > > > + ip = ftrace_regs_caller_ret;
> > > > + ret = probe_kernel_read(ip, (void *)retq, RET_SIZE);
> > > > + if (WARN_ON(ret < 0))
> > > > + goto fail;
> > > > + }
> > > > +
> > >
> > > Hm? This function creates a trampoline but it looks like this change is
> > > overwriting the original ftrace_64 code itself?
> >
> > Ahh. So if you look at what the trampoline copies, you'll note we'll
> > copy until -- but *NOT* including -- the jmp ftrace_epilogue. Instead
> > we'll write a RET at the end.
> >
> > However, due to splitting the return path, such that each instruction
> > has a unique stack offset, we now have a second jmp ftrace_epilogue in
> > the middle of the function. That too needs to be overwritten by a RET.
>
> Right, but 'ip' needs to point to the trampoline's version of
> 'ftrace_regs_caller_ret', not the original ftrace_64 version.
I noticed the same thing. And after applying just this patch (with tweaking
the obtool mark ups to make it compile) it crashed.
-- Steve
Powered by blists - more mailing lists