On Wed, 28 Oct 2020 14:33:03 -0700 Alexei Starovoitov <[email protected]> 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
