[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201028180753.238335d1@oasis.local.home>
Date: Wed, 28 Oct 2020 18:07:53 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: linux-kernel@...r.kernel.org,
Masami Hiramatsu <mhiramat@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Olsa <jolsa@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC][PATCH 0/2] ftrace: Add access to function arguments for
all callbacks
On Wed, 28 Oct 2020 14:33:03 -0700
Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> I don't have strong opinion on this feature, but if you want to have it
> please add a giant disclaimer that this is going to be x86-64 and, may be arm64,
> feature _forever_. On x86-32 and other architectures there is no way
> to provide sane regs_get_kernel_argument(regs, n) semantics by blindly
> saving registers. The kernel needs to know types and calling convention
> of the architecture. That's the reason bpf side has btf_func_model concept.
> To make sure that bpf trampoline can support all architectures in the future.
The trampoline is to only provide the information to get the arguments.
Yes, it is up to the callback that registered it that knows how to get them.
What does the bpf trampoline need to get an argument if it already
knows the type. If it has access to a subset of necessary registers and
the stack pointer of when the function was called, is it possible to
figure out the arguments?
This code is not about a "regs_get_kernel_argument(regs, n)", that was
only used to show that *that* could be done. Because currently, there's
*no* way to get those arguments without setting the SAVE_REGS flag,
which saves way more than necessary. I only used that to test the code
in a generic way. Ideally, ftrace could use btf to figure out the
actual arguments of the function if it had a mapping.
I believe the reason you gave up on using ftrace was because of the
overhead of the REGS code. If that wasn't the case, and you didn't see
that overhead, would you have used ftrace?
In fact, did you look at all to see if you could modify the current
infrastructure to make it work for you? Or did you just give up to
write your own from scratch?
-- Steve
Powered by blists - more mailing lists