From: Yonghong Song <yhs@fb.com>
To: Daniel Borkmann <daniel@iogearbox.net>, <ast@kernel.org>
Cc: <john.fastabend@gmail.com>, <netdev@vger.kernel.org>,
<bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 4/6] bpf, libbpf: add bpf_tail_call_static helper for bpf programs
Date: Thu, 24 Sep 2020 23:13:05 -0700 [thread overview]
Message-ID: <c5996fbb-e546-d6e1-7903-f773e2ffb43e@fb.com> (raw)
In-Reply-To: <ae48d5b3c4b6b7ee1285c3167c3aa38ae3fdc093.1600967205.git.daniel@iogearbox.net>
On 9/24/20 11:21 AM, Daniel Borkmann wrote:
> Port of tail_call_static() helper function from Cilium's BPF code base [0]
> to libbpf, so others can easily consume it as well. We've been using this
> in production code for some time now. The main idea is that we guarantee
> that the kernel's BPF infrastructure and JIT (here: x86_64) can patch the
> JITed BPF insns with direct jumps instead of having to fall back to using
> expensive retpolines. By using inline asm, we guarantee that the compiler
> won't merge the call from different paths with potentially different
> content of r2/r3.
>
> We're also using __throw_build_bug() macro in different places as a neat
> trick to trigger compilation errors when compiler does not remove code at
> compilation time. This works for the BPF backend as it does not implement
> the __builtin_trap().
>
> [0] https://github.com/cilium/cilium/commit/f5537c26020d5297b70936c6b7d03a1e412a1035
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> tools/lib/bpf/bpf_helpers.h | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
> index 1106777df00b..18b75a4c82e6 100644
> --- a/tools/lib/bpf/bpf_helpers.h
> +++ b/tools/lib/bpf/bpf_helpers.h
> @@ -53,6 +53,38 @@
> })
> #endif
>
> +/*
> + * Misc useful helper macros
> + */
> +#ifndef __throw_build_bug
> +# define __throw_build_bug() __builtin_trap()
Just some general comments below. The patch itself is fine to me.
I guess we will never implement a 'trap' insn? The only possible
use I know is for failed CORE relocation, which currently encoded
as an illegal call insn.
> +#endif
> +
> +static __always_inline void
> +bpf_tail_call_static(void *ctx, const void *map, const __u32 slot)
> +{
> + if (!__builtin_constant_p(slot))
> + __throw_build_bug();
> +
> + /*
> + * Don't gamble, but _guarantee_ that LLVM won't optimize setting
> + * r2 and r3 from different paths ending up at the same call insn as
> + * otherwise we won't be able to use the jmpq/nopl retpoline-free
> + * patching by the x86-64 JIT in the kernel.
> + *
> + * Note on clobber list: we need to stay in-line with BPF calling
> + * convention, so even if we don't end up using r0, r4, r5, we need
> + * to mark them as clobber so that LLVM doesn't end up using them
> + * before / after the call.
> + */
> + asm volatile("r1 = %[ctx]\n\t"
> + "r2 = %[map]\n\t"
> + "r3 = %[slot]\n\t"
> + "call 12\n\t"
> + :: [ctx]"r"(ctx), [map]"r"(map), [slot]"i"(slot)
> + : "r0", "r1", "r2", "r3", "r4", "r5");
Clever scheme to enforce a constant!
This particular case is to avoid sinking common code.
We have a similar use case in https://reviews.llvm.org/D87153
which is to avoid PHI merging of two relocation globals like
phi = [reloc_global1, reloc_global2] // reachable from two paths
... phi ...
The solution is to insert bpf internal __builtin
val = __builtin_bpf_passthrough(seq_num, val)
in proper places to prevent sinking common code.
I guess in this example, we could prevent this with
compiler inserting passthrough builtin's like
...
ret = bpf_tail_call(ctx, map, slot)
ret = __builtin_bpf_passthrough(seq_num, ret)
...
If in the future, such a builtin is proved useful for bpf program
writers as well. we could just define
val = __builtin_bpf_passthrough(val)
and internally, it will be transformed to
val = llvm.bpf.passthrough(seq_num, val)
> +}
> +
> /*
> * Helper structure used by eBPF C program
> * to describe BPF map attributes to libbpf loader
>
next prev parent reply other threads:[~2020-09-25 6:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 18:21 [PATCH bpf-next 0/6] Various BPF helper improvements Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 1/6] bpf: add classid helper only based on skb->sk Daniel Borkmann
2020-09-25 14:46 ` Jakub Kicinski
2020-09-25 15:35 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 2/6] bpf, net: rework cookie generator as per-cpu one Daniel Borkmann
2020-09-24 18:58 ` Eric Dumazet
2020-09-24 22:03 ` Daniel Borkmann
2020-09-25 7:49 ` Eric Dumazet
2020-09-25 9:26 ` Daniel Borkmann
2020-09-25 15:00 ` Jakub Kicinski
2020-09-25 15:15 ` Eric Dumazet
2020-09-25 15:31 ` Jakub Kicinski
2020-09-25 15:45 ` Eric Dumazet
2020-09-24 18:21 ` [PATCH bpf-next 3/6] bpf: add redirect_neigh helper as redirect drop-in Daniel Borkmann
2020-09-24 22:12 ` David Ahern
2020-09-24 22:19 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 4/6] bpf, libbpf: add bpf_tail_call_static helper for bpf programs Daniel Borkmann
2020-09-24 20:53 ` Andrii Nakryiko
2020-09-24 22:17 ` Daniel Borkmann
2020-09-25 15:42 ` Daniel Borkmann
2020-09-25 15:52 ` Daniel Borkmann
2020-09-25 16:50 ` Andrii Nakryiko
2020-09-25 19:52 ` Daniel Borkmann
2020-09-25 6:13 ` Yonghong Song [this message]
2020-09-24 18:21 ` [PATCH bpf-next 5/6] bpf, selftests: use bpf_tail_call_static where appropriate Daniel Borkmann
2020-09-24 19:25 ` Maciej Fijalkowski
2020-09-24 22:03 ` Daniel Borkmann
2020-09-24 18:21 ` [PATCH bpf-next 6/6] bpf, selftests: add redirect_neigh selftest Daniel Borkmann
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=c5996fbb-e546-d6e1-7903-f773e2ffb43e@fb.com \
--to=yhs@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.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).