diff options
author | 2020-08-19 12:45:15 -0700 | |
---|---|---|
committer | 2020-08-19 14:19:39 -0700 | |
commit | 3fc32f40c40207bf85ce1b007f18981c4673df96 (patch) | |
tree | 1a97d48c7887152a80f435822642bb494366b3f9 /net/ipv4/tcp_fastopen.c | |
parent | net-veth: Add type safety to veth_xdp_to_ptr() and veth_ptr_to_xdp() (diff) | |
download | wireguard-linux-3fc32f40c40207bf85ce1b007f18981c4673df96.tar.xz wireguard-linux-3fc32f40c40207bf85ce1b007f18981c4673df96.zip |
libbpf: Implement type-based CO-RE relocations support
Implement support for TYPE_EXISTS/TYPE_SIZE/TYPE_ID_LOCAL/TYPE_ID_REMOTE
relocations. These are examples of type-based relocations, as opposed to
field-based relocations supported already. The difference is that they are
calculating relocation values based on the type itself, not a field within
a struct/union.
Type-based relos have slightly different semantics when matching local types
to kernel target types, see comments in bpf_core_types_are_compat() for
details. Their behavior on failure to find target type in kernel BTF also
differs. Instead of "poisoning" relocatable instruction and failing load
subsequently in kernel, they return 0 (which is rarely a valid return result,
so user BPF code can use that to detect success/failure of the relocation and
deal with it without extra "guarding" relocations). Also, it's always possible
to check existence of the type in target kernel with TYPE_EXISTS relocation,
similarly to a field-based FIELD_EXISTS.
TYPE_ID_LOCAL relocation is a bit special in that it always succeeds (barring
any libbpf/Clang bugs) and resolved to BTF ID using **local** BTF info of BPF
program itself. Tests in subsequent patches demonstrate the usage and
semantics of new relocations.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20200819194519.3375898-2-andriin@fb.com
Diffstat (limited to 'net/ipv4/tcp_fastopen.c')
0 files changed, 0 insertions, 0 deletions