[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240930150302.6c5c9f0a@gandalf.local.home>
Date: Mon, 30 Sep 2024 15:03:02 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Will Deacon <will@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
linux-arm-kernel@...ts.infradead.org, "Masami Hiramatsu (Google)"
<mhiramat@...nel.org>, Florent Revest <revest@...omium.org>,
linux-trace-kernel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>, Jiri Olsa <jolsa@...nel.org>, Arnaldo
Carvalho de Melo <acme@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v14 05/19] function_graph: Pass ftrace_regs to retfunc
On Tue, 17 Sep 2024 11:08:48 +0100
Will Deacon <will@...nel.org> wrote:
> > > @@ -787,6 +789,9 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe
> > > }
> > >
> > > trace.rettime = trace_clock_local();
> > > + if (fregs)
> > > + ftrace_regs_set_instruction_pointer(fregs, ret);
>
> Where does the instruction pointer get used after this? The arm64
> 'return_to_handler' function doesn't look at it when we return.
It's for the hooks to the return instruction. kretprobes will start using
function graph tracer to hook to a return of a function (via fprobes), and
the callbacks will need access to the return pointer. The callbacks get
passed the ftrace_regs, and this is how they can see what the function is
returning to. For example, BPF programs will need this.
So it's not needed for the infrastructure, only the callbacks that hook to
it.
-- Steve
Powered by blists - more mailing lists