lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 26 Oct 2020 21:30:14 -0700 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Steven Rostedt <rostedt@...dmis.org> Cc: Jiri Olsa <jolsa@...hat.com>, Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andriin@...com>, netdev@...r.kernel.org, bpf@...r.kernel.org, Martin KaFai Lau <kafai@...com>, Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...omium.org>, Daniel Xu <dxu@...uu.xyz>, Jesper Brouer <jbrouer@...hat.com>, Toke Høiland-Jørgensen <toke@...hat.com>, Viktor Malik <vmalik@...hat.com> Subject: Re: [RFC bpf-next 00/16] bpf: Speed up trampoline attach On Thu, Oct 22, 2020 at 10:42:05AM -0400, Steven Rostedt wrote: > On Thu, 22 Oct 2020 16:11:54 +0200 > Jiri Olsa <jolsa@...hat.com> wrote: > > > I understand direct calls as a way that bpf trampolines and ftrace can > > co-exist together - ebpf trampolines need that functionality of accessing > > parameters of a function as if it was called directly and at the same > > point we need to be able attach to any function and to as many functions > > as we want in a fast way > > I was sold that bpf needed a quick and fast way to get the arguments of a > function, as the only way to do that with ftrace is to save all registers, > which, I was told was too much overhead, as if you only care about > arguments, there's much less that is needed to save. > > Direct calls wasn't added so that bpf and ftrace could co-exist, it was > that for certain cases, bpf wanted a faster way to access arguments, > because it still worked with ftrace, but the saving of regs was too > strenuous. Direct calls in ftrace were done so that ftrace and trampoline can co-exist. There is no other use for it. Jiri, could you please redo your benchmarking hardcoding ftrace_managed=false ? If going through register_ftrace_direct() is indeed so much slower than arch_text_poke() then something gotta give. Either register_ftrace_direct() has to become faster or users have to give up on co-existing of bpf and ftrace. So far not a single user cared about using trampoline and ftrace together. So the latter is certainly an option. Regardless, the patch 7 (rbtree of kallsyms) is probably good on its own. Can you benchmark it independently and maybe resubmit if it's useful without other patches?
Powered by blists - more mailing lists