bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Alexei Starovoitov <ast@kernel.org>
Cc: davem@davemloft.net, daniel@iogearbox.net, peterz@infradead.org,
	rostedt@goodmis.org, x86@kernel.org, netdev@vger.kernel.org,
	bpf@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH bpf-next 0/7] Introduce BPF trampoline
Date: Tue, 5 Nov 2019 06:31:56 -0800	[thread overview]
Message-ID: <20191105143154.umojkotnvcx4yeuq@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <20191102220025.2475981-1-ast@kernel.org>

On Sat, Nov 02, 2019 at 03:00:18PM -0700, Alexei Starovoitov wrote:
> Introduce BPF trampoline that works as a bridge between kernel functions and
> BPF programs. The first use case is fentry/fexit BPF programs that are roughly
> equivalent to kprobe/kretprobe. Unlike k[ret]probe there is practically zero
> overhead to call a set of BPF programs before or after kernel function. In the
> future patches networking use cases will be explored. For example: BPF
> trampoline can be used to call XDP programs from drivers with direct calls or
> wrapping BPF program into another BPF program.
> 
> The patch set depends on register_ftrace_direct() API. It's not upstream yet
> and available in [1]. The first patch is a hack to workaround this dependency.
> The idea is to land this set via bpf-next tree and land register_ftrace_direct
> via Steven's ftrace tree. Then during the merge window revert the first patch.
> Steven,
> do you think it's workable?
> As an alternative we can route register_ftrace_direct patches via bpf-next ?
> 
> Peter's static_call patches [2] are solving the issue of indirect call overhead
> for large class of kernel use cases, but unfortunately don't help calling into
> a set of BPF programs.  BPF trampoline's first goal is to translate kernel
> calling convention into BPF calling convention. The second goal is to call a
> set of programs efficiently. In the future we can replace BPF_PROG_RUN_ARRAY
> with BPF trampoline variant. Another future work is to add support for static_key,
> static_jmp and static_call inside generated BPF trampoline.
> 
> Please see patch 3 for details.
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git/commit/?h=ftrace/direct&id=3ac423d902727884a389699fd7294c0e2e94b29c

Steven,
look slike your branch hasn't been updated in 13 days.
Are you still planning to fix the bugs and send it in for the merge window?
I cannot afford to wait a full release, since I have my own follow for
XDP/networking based on this and other folks are building their stuff on top of
BPF trampoline too. So I'm thinking for v2 I will switch to using text_poke()
and add appropriate guard checks, so it will be safe out of the box without
ftrace dependency. If register_ftrace_direct() indeed comes in soon I'll
switch to that and will make bpf trampoline to co-operate with ftrace.
text_poke approach will make it such that what ever comes first to trace the
fentry (either bpf trampoline or ftrace) will grab the nop and the other system
will not be able to attach. That's safe and correct, but certainly not nice
long term. So the fix will be needed. The key point that switching to text_poke
will remove the register_ftrace_direct() dependency, unblock bpf developers and
will give you time to land your stuff at your pace.


  parent reply	other threads:[~2019-11-05 14:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-02 22:00 [PATCH bpf-next 0/7] Introduce BPF trampoline Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 1/7] bpf, ftrace: temporary workaround Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 2/7] bpf: refactor x86 JIT into helpers Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 3/7] bpf: Introduce BPF trampoline Alexei Starovoitov
2019-11-05 19:51   ` Andrii Nakryiko
2019-11-02 22:00 ` [PATCH bpf-next 4/7] libbpf: Add support to attach to fentry/fexit tracing progs Alexei Starovoitov
2019-11-05 21:17   ` Andrii Nakryiko
2019-11-05 23:17     ` Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 5/7] selftest/bpf: Simple test for fentry/fexit Alexei Starovoitov
2019-11-05 21:37   ` Andrii Nakryiko
2019-11-02 22:00 ` [PATCH bpf-next 6/7] bpf: Add kernel test functions for fentry testing Alexei Starovoitov
2019-11-02 22:00 ` [PATCH bpf-next 7/7] selftests/bpf: Add test for BPF trampoline Alexei Starovoitov
2019-11-05 21:50   ` Andrii Nakryiko
2019-11-05 14:31 ` Alexei Starovoitov [this message]
2019-11-05 15:40   ` [PATCH bpf-next 0/7] Introduce " Steven Rostedt
2019-11-05 15:47     ` Alexei Starovoitov
2019-11-05 16:00       ` Steven Rostedt
2019-11-05 16:28         ` Alexei Starovoitov
2019-11-05 17:26           ` Steven Rostedt
2019-11-05 17:59             ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191105143154.umojkotnvcx4yeuq@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).