2019-02-04 13:28:44 -08:00
|
|
|
LIBBPF_0.0.1 {
|
|
|
|
|
global:
|
|
|
|
|
bpf_btf_get_fd_by_id;
|
|
|
|
|
bpf_create_map;
|
|
|
|
|
bpf_create_map_in_map;
|
|
|
|
|
bpf_create_map_in_map_node;
|
|
|
|
|
bpf_create_map_name;
|
|
|
|
|
bpf_create_map_node;
|
|
|
|
|
bpf_create_map_xattr;
|
|
|
|
|
bpf_load_btf;
|
|
|
|
|
bpf_load_program;
|
|
|
|
|
bpf_load_program_xattr;
|
|
|
|
|
bpf_map__btf_key_type_id;
|
|
|
|
|
bpf_map__btf_value_type_id;
|
|
|
|
|
bpf_map__def;
|
|
|
|
|
bpf_map__fd;
|
|
|
|
|
bpf_map__is_offload_neutral;
|
|
|
|
|
bpf_map__name;
|
|
|
|
|
bpf_map__next;
|
|
|
|
|
bpf_map__pin;
|
|
|
|
|
bpf_map__prev;
|
|
|
|
|
bpf_map__priv;
|
|
|
|
|
bpf_map__reuse_fd;
|
|
|
|
|
bpf_map__set_ifindex;
|
|
|
|
|
bpf_map__set_inner_map_fd;
|
|
|
|
|
bpf_map__set_priv;
|
|
|
|
|
bpf_map__unpin;
|
|
|
|
|
bpf_map_delete_elem;
|
|
|
|
|
bpf_map_get_fd_by_id;
|
|
|
|
|
bpf_map_get_next_id;
|
|
|
|
|
bpf_map_get_next_key;
|
|
|
|
|
bpf_map_lookup_and_delete_elem;
|
|
|
|
|
bpf_map_lookup_elem;
|
|
|
|
|
bpf_map_update_elem;
|
|
|
|
|
bpf_obj_get;
|
|
|
|
|
bpf_obj_get_info_by_fd;
|
|
|
|
|
bpf_obj_pin;
|
|
|
|
|
bpf_object__btf_fd;
|
|
|
|
|
bpf_object__close;
|
|
|
|
|
bpf_object__find_map_by_name;
|
|
|
|
|
bpf_object__find_map_by_offset;
|
|
|
|
|
bpf_object__find_program_by_title;
|
|
|
|
|
bpf_object__kversion;
|
|
|
|
|
bpf_object__load;
|
|
|
|
|
bpf_object__name;
|
|
|
|
|
bpf_object__next;
|
|
|
|
|
bpf_object__open;
|
|
|
|
|
bpf_object__open_buffer;
|
|
|
|
|
bpf_object__open_xattr;
|
|
|
|
|
bpf_object__pin;
|
|
|
|
|
bpf_object__pin_maps;
|
|
|
|
|
bpf_object__pin_programs;
|
|
|
|
|
bpf_object__priv;
|
|
|
|
|
bpf_object__set_priv;
|
|
|
|
|
bpf_object__unload;
|
|
|
|
|
bpf_object__unpin_maps;
|
|
|
|
|
bpf_object__unpin_programs;
|
|
|
|
|
bpf_perf_event_read_simple;
|
|
|
|
|
bpf_prog_attach;
|
|
|
|
|
bpf_prog_detach;
|
|
|
|
|
bpf_prog_detach2;
|
|
|
|
|
bpf_prog_get_fd_by_id;
|
|
|
|
|
bpf_prog_get_next_id;
|
|
|
|
|
bpf_prog_load;
|
|
|
|
|
bpf_prog_load_xattr;
|
|
|
|
|
bpf_prog_query;
|
|
|
|
|
bpf_prog_test_run;
|
|
|
|
|
bpf_prog_test_run_xattr;
|
|
|
|
|
bpf_program__fd;
|
|
|
|
|
bpf_program__is_kprobe;
|
|
|
|
|
bpf_program__is_perf_event;
|
|
|
|
|
bpf_program__is_raw_tracepoint;
|
|
|
|
|
bpf_program__is_sched_act;
|
|
|
|
|
bpf_program__is_sched_cls;
|
|
|
|
|
bpf_program__is_socket_filter;
|
|
|
|
|
bpf_program__is_tracepoint;
|
|
|
|
|
bpf_program__is_xdp;
|
|
|
|
|
bpf_program__load;
|
|
|
|
|
bpf_program__next;
|
|
|
|
|
bpf_program__nth_fd;
|
|
|
|
|
bpf_program__pin;
|
|
|
|
|
bpf_program__pin_instance;
|
|
|
|
|
bpf_program__prev;
|
|
|
|
|
bpf_program__priv;
|
|
|
|
|
bpf_program__set_expected_attach_type;
|
|
|
|
|
bpf_program__set_ifindex;
|
|
|
|
|
bpf_program__set_kprobe;
|
|
|
|
|
bpf_program__set_perf_event;
|
|
|
|
|
bpf_program__set_prep;
|
|
|
|
|
bpf_program__set_priv;
|
|
|
|
|
bpf_program__set_raw_tracepoint;
|
|
|
|
|
bpf_program__set_sched_act;
|
|
|
|
|
bpf_program__set_sched_cls;
|
|
|
|
|
bpf_program__set_socket_filter;
|
|
|
|
|
bpf_program__set_tracepoint;
|
|
|
|
|
bpf_program__set_type;
|
|
|
|
|
bpf_program__set_xdp;
|
|
|
|
|
bpf_program__title;
|
|
|
|
|
bpf_program__unload;
|
|
|
|
|
bpf_program__unpin;
|
|
|
|
|
bpf_program__unpin_instance;
|
|
|
|
|
bpf_prog_linfo__free;
|
|
|
|
|
bpf_prog_linfo__new;
|
|
|
|
|
bpf_prog_linfo__lfind_addr_func;
|
|
|
|
|
bpf_prog_linfo__lfind;
|
|
|
|
|
bpf_raw_tracepoint_open;
|
|
|
|
|
bpf_set_link_xdp_fd;
|
|
|
|
|
bpf_task_fd_query;
|
|
|
|
|
bpf_verify_program;
|
|
|
|
|
btf__fd;
|
|
|
|
|
btf__find_by_name;
|
|
|
|
|
btf__free;
|
|
|
|
|
btf__get_from_id;
|
|
|
|
|
btf__name_by_offset;
|
|
|
|
|
btf__new;
|
|
|
|
|
btf__resolve_size;
|
|
|
|
|
btf__resolve_type;
|
|
|
|
|
btf__type_by_id;
|
|
|
|
|
libbpf_attach_type_by_name;
|
|
|
|
|
libbpf_get_error;
|
|
|
|
|
libbpf_prog_type_by_name;
|
|
|
|
|
libbpf_set_print;
|
|
|
|
|
libbpf_strerror;
|
|
|
|
|
local:
|
|
|
|
|
*;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
LIBBPF_0.0.2 {
|
|
|
|
|
global:
|
|
|
|
|
bpf_probe_helper;
|
|
|
|
|
bpf_probe_map_type;
|
|
|
|
|
bpf_probe_prog_type;
|
2019-02-15 08:50:10 -08:00
|
|
|
bpf_map__resize;
|
2019-02-04 13:28:44 -08:00
|
|
|
bpf_map_lookup_elem_flags;
|
2019-02-15 08:50:10 -08:00
|
|
|
bpf_object__btf;
|
2019-02-04 13:28:44 -08:00
|
|
|
bpf_object__find_map_fd_by_name;
|
|
|
|
|
bpf_get_link_xdp_id;
|
2019-02-07 21:58:07 -08:00
|
|
|
btf__dedup;
|
2019-02-04 13:28:44 -08:00
|
|
|
btf__get_map_kv_tids;
|
2019-02-07 21:58:07 -08:00
|
|
|
btf__get_nr_types;
|
2019-02-15 07:38:45 -08:00
|
|
|
btf__get_raw_data;
|
|
|
|
|
btf__load;
|
2019-02-04 13:28:44 -08:00
|
|
|
btf_ext__free;
|
|
|
|
|
btf_ext__func_info_rec_size;
|
2019-02-15 07:38:45 -08:00
|
|
|
btf_ext__get_raw_data;
|
2019-02-04 13:28:44 -08:00
|
|
|
btf_ext__line_info_rec_size;
|
|
|
|
|
btf_ext__new;
|
|
|
|
|
btf_ext__reloc_func_info;
|
|
|
|
|
btf_ext__reloc_line_info;
|
2019-02-21 10:21:26 +01:00
|
|
|
xsk_umem__create;
|
|
|
|
|
xsk_socket__create;
|
|
|
|
|
xsk_umem__delete;
|
|
|
|
|
xsk_socket__delete;
|
|
|
|
|
xsk_umem__fd;
|
|
|
|
|
xsk_socket__fd;
|
2019-03-11 22:30:38 -07:00
|
|
|
bpf_program__get_prog_info_linear;
|
|
|
|
|
bpf_program__bpil_addr_to_offs;
|
|
|
|
|
bpf_program__bpil_offs_to_addr;
|
2019-02-04 13:28:44 -08:00
|
|
|
} LIBBPF_0.0.1;
|
bpf, libbpf: support global data/bss/rodata sections
This work adds BPF loader support for global data sections
to libbpf. This allows to write BPF programs in more natural
C-like way by being able to define global variables and const
data.
Back at LPC 2018 [0] we presented a first prototype which
implemented support for global data sections by extending BPF
syscall where union bpf_attr would get additional memory/size
pair for each section passed during prog load in order to later
add this base address into the ldimm64 instruction along with
the user provided offset when accessing a variable. Consensus
from LPC was that for proper upstream support, it would be
more desirable to use maps instead of bpf_attr extension as
this would allow for introspection of these sections as well
as potential live updates of their content. This work follows
this path by taking the following steps from loader side:
1) In bpf_object__elf_collect() step we pick up ".data",
".rodata", and ".bss" section information.
2) If present, in bpf_object__init_internal_map() we add
maps to the obj's map array that corresponds to each
of the present sections. Given section size and access
properties can differ, a single entry array map is
created with value size that is corresponding to the
ELF section size of .data, .bss or .rodata. These
internal maps are integrated into the normal map
handling of libbpf such that when user traverses all
obj maps, they can be differentiated from user-created
ones via bpf_map__is_internal(). In later steps when
we actually create these maps in the kernel via
bpf_object__create_maps(), then for .data and .rodata
sections their content is copied into the map through
bpf_map_update_elem(). For .bss this is not necessary
since array map is already zero-initialized by default.
Additionally, for .rodata the map is frozen as read-only
after setup, such that neither from program nor syscall
side writes would be possible.
3) In bpf_program__collect_reloc() step, we record the
corresponding map, insn index, and relocation type for
the global data.
4) And last but not least in the actual relocation step in
bpf_program__relocate(), we mark the ldimm64 instruction
with src_reg = BPF_PSEUDO_MAP_VALUE where in the first
imm field the map's file descriptor is stored as similarly
done as in BPF_PSEUDO_MAP_FD, and in the second imm field
(as ldimm64 is 2-insn wide) we store the access offset
into the section. Given these maps have only single element
ldimm64's off remains zero in both parts.
5) On kernel side, this special marked BPF_PSEUDO_MAP_VALUE
load will then store the actual target address in order
to have a 'map-lookup'-free access. That is, the actual
map value base address + offset. The destination register
in the verifier will then be marked as PTR_TO_MAP_VALUE,
containing the fixed offset as reg->off and backing BPF
map as reg->map_ptr. Meaning, it's treated as any other
normal map value from verification side, only with
efficient, direct value access instead of actual call to
map lookup helper as in the typical case.
Currently, only support for static global variables has been
added, and libbpf rejects non-static global variables from
loading. This can be lifted until we have proper semantics
for how BPF will treat multi-object BPF loads. From BTF side,
libbpf will set the value type id of the types corresponding
to the ".bss", ".data" and ".rodata" names which LLVM will
emit without the object name prefix. The key type will be
left as zero, thus making use of the key-less BTF option in
array maps.
Simple example dump of program using globals vars in each
section:
# bpftool prog
[...]
6784: sched_cls name load_static_dat tag a7e1291567277844 gpl
loaded_at 2019-03-11T15:39:34+0000 uid 0
xlated 1776B jited 993B memlock 4096B map_ids 2238,2237,2235,2236,2239,2240
# bpftool map show id 2237
2237: array name test_glo.bss flags 0x0
key 4B value 64B max_entries 1 memlock 4096B
# bpftool map show id 2235
2235: array name test_glo.data flags 0x0
key 4B value 64B max_entries 1 memlock 4096B
# bpftool map show id 2236
2236: array name test_glo.rodata flags 0x80
key 4B value 96B max_entries 1 memlock 4096B
# bpftool prog dump xlated id 6784
int load_static_data(struct __sk_buff * skb):
; int load_static_data(struct __sk_buff *skb)
0: (b7) r6 = 0
; test_reloc(number, 0, &num0);
1: (63) *(u32 *)(r10 -4) = r6
2: (bf) r2 = r10
; int load_static_data(struct __sk_buff *skb)
3: (07) r2 += -4
; test_reloc(number, 0, &num0);
4: (18) r1 = map[id:2238]
6: (18) r3 = map[id:2237][0]+0 <-- direct addr in .bss area
8: (b7) r4 = 0
9: (85) call array_map_update_elem#100464
10: (b7) r1 = 1
; test_reloc(number, 1, &num1);
[...]
; test_reloc(string, 2, str2);
120: (18) r8 = map[id:2237][0]+16 <-- same here at offset +16
122: (18) r1 = map[id:2239]
124: (18) r3 = map[id:2237][0]+16
126: (b7) r4 = 0
127: (85) call array_map_update_elem#100464
128: (b7) r1 = 120
; str1[5] = 'x';
129: (73) *(u8 *)(r9 +5) = r1
; test_reloc(string, 3, str1);
130: (b7) r1 = 3
131: (63) *(u32 *)(r10 -4) = r1
132: (b7) r9 = 3
133: (bf) r2 = r10
; int load_static_data(struct __sk_buff *skb)
134: (07) r2 += -4
; test_reloc(string, 3, str1);
135: (18) r1 = map[id:2239]
137: (18) r3 = map[id:2235][0]+16 <-- direct addr in .data area
139: (b7) r4 = 0
140: (85) call array_map_update_elem#100464
141: (b7) r1 = 111
; __builtin_memcpy(&str2[2], "hello", sizeof("hello"));
142: (73) *(u8 *)(r8 +6) = r1 <-- further access based on .bss data
143: (b7) r1 = 108
144: (73) *(u8 *)(r8 +5) = r1
[...]
For Cilium use-case in particular, this enables migrating configuration
constants from Cilium daemon's generated header defines into global
data sections such that expensive runtime recompilations with LLVM can
be avoided altogether. Instead, the ELF file becomes effectively a
"template", meaning, it is compiled only once (!) and the Cilium daemon
will then rewrite relevant configuration data from the ELF's .data or
.rodata sections directly instead of recompiling the program. The
updated ELF is then loaded into the kernel and atomically replaces
the existing program in the networking datapath. More info in [0].
Based upon recent fix in LLVM, commit c0db6b6bd444 ("[BPF] Don't fail
for static variables").
[0] LPC 2018, BPF track, "ELF relocation for static data in BPF",
http://vger.kernel.org/lpc-bpf2018.html#session-3
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-09 23:20:13 +02:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.3 {
|
|
|
|
|
global:
|
|
|
|
|
bpf_map__is_internal;
|
|
|
|
|
bpf_map_freeze;
|
2019-04-09 23:20:14 +02:00
|
|
|
btf__finalize_data;
|
bpf, libbpf: support global data/bss/rodata sections
This work adds BPF loader support for global data sections
to libbpf. This allows to write BPF programs in more natural
C-like way by being able to define global variables and const
data.
Back at LPC 2018 [0] we presented a first prototype which
implemented support for global data sections by extending BPF
syscall where union bpf_attr would get additional memory/size
pair for each section passed during prog load in order to later
add this base address into the ldimm64 instruction along with
the user provided offset when accessing a variable. Consensus
from LPC was that for proper upstream support, it would be
more desirable to use maps instead of bpf_attr extension as
this would allow for introspection of these sections as well
as potential live updates of their content. This work follows
this path by taking the following steps from loader side:
1) In bpf_object__elf_collect() step we pick up ".data",
".rodata", and ".bss" section information.
2) If present, in bpf_object__init_internal_map() we add
maps to the obj's map array that corresponds to each
of the present sections. Given section size and access
properties can differ, a single entry array map is
created with value size that is corresponding to the
ELF section size of .data, .bss or .rodata. These
internal maps are integrated into the normal map
handling of libbpf such that when user traverses all
obj maps, they can be differentiated from user-created
ones via bpf_map__is_internal(). In later steps when
we actually create these maps in the kernel via
bpf_object__create_maps(), then for .data and .rodata
sections their content is copied into the map through
bpf_map_update_elem(). For .bss this is not necessary
since array map is already zero-initialized by default.
Additionally, for .rodata the map is frozen as read-only
after setup, such that neither from program nor syscall
side writes would be possible.
3) In bpf_program__collect_reloc() step, we record the
corresponding map, insn index, and relocation type for
the global data.
4) And last but not least in the actual relocation step in
bpf_program__relocate(), we mark the ldimm64 instruction
with src_reg = BPF_PSEUDO_MAP_VALUE where in the first
imm field the map's file descriptor is stored as similarly
done as in BPF_PSEUDO_MAP_FD, and in the second imm field
(as ldimm64 is 2-insn wide) we store the access offset
into the section. Given these maps have only single element
ldimm64's off remains zero in both parts.
5) On kernel side, this special marked BPF_PSEUDO_MAP_VALUE
load will then store the actual target address in order
to have a 'map-lookup'-free access. That is, the actual
map value base address + offset. The destination register
in the verifier will then be marked as PTR_TO_MAP_VALUE,
containing the fixed offset as reg->off and backing BPF
map as reg->map_ptr. Meaning, it's treated as any other
normal map value from verification side, only with
efficient, direct value access instead of actual call to
map lookup helper as in the typical case.
Currently, only support for static global variables has been
added, and libbpf rejects non-static global variables from
loading. This can be lifted until we have proper semantics
for how BPF will treat multi-object BPF loads. From BTF side,
libbpf will set the value type id of the types corresponding
to the ".bss", ".data" and ".rodata" names which LLVM will
emit without the object name prefix. The key type will be
left as zero, thus making use of the key-less BTF option in
array maps.
Simple example dump of program using globals vars in each
section:
# bpftool prog
[...]
6784: sched_cls name load_static_dat tag a7e1291567277844 gpl
loaded_at 2019-03-11T15:39:34+0000 uid 0
xlated 1776B jited 993B memlock 4096B map_ids 2238,2237,2235,2236,2239,2240
# bpftool map show id 2237
2237: array name test_glo.bss flags 0x0
key 4B value 64B max_entries 1 memlock 4096B
# bpftool map show id 2235
2235: array name test_glo.data flags 0x0
key 4B value 64B max_entries 1 memlock 4096B
# bpftool map show id 2236
2236: array name test_glo.rodata flags 0x80
key 4B value 96B max_entries 1 memlock 4096B
# bpftool prog dump xlated id 6784
int load_static_data(struct __sk_buff * skb):
; int load_static_data(struct __sk_buff *skb)
0: (b7) r6 = 0
; test_reloc(number, 0, &num0);
1: (63) *(u32 *)(r10 -4) = r6
2: (bf) r2 = r10
; int load_static_data(struct __sk_buff *skb)
3: (07) r2 += -4
; test_reloc(number, 0, &num0);
4: (18) r1 = map[id:2238]
6: (18) r3 = map[id:2237][0]+0 <-- direct addr in .bss area
8: (b7) r4 = 0
9: (85) call array_map_update_elem#100464
10: (b7) r1 = 1
; test_reloc(number, 1, &num1);
[...]
; test_reloc(string, 2, str2);
120: (18) r8 = map[id:2237][0]+16 <-- same here at offset +16
122: (18) r1 = map[id:2239]
124: (18) r3 = map[id:2237][0]+16
126: (b7) r4 = 0
127: (85) call array_map_update_elem#100464
128: (b7) r1 = 120
; str1[5] = 'x';
129: (73) *(u8 *)(r9 +5) = r1
; test_reloc(string, 3, str1);
130: (b7) r1 = 3
131: (63) *(u32 *)(r10 -4) = r1
132: (b7) r9 = 3
133: (bf) r2 = r10
; int load_static_data(struct __sk_buff *skb)
134: (07) r2 += -4
; test_reloc(string, 3, str1);
135: (18) r1 = map[id:2239]
137: (18) r3 = map[id:2235][0]+16 <-- direct addr in .data area
139: (b7) r4 = 0
140: (85) call array_map_update_elem#100464
141: (b7) r1 = 111
; __builtin_memcpy(&str2[2], "hello", sizeof("hello"));
142: (73) *(u8 *)(r8 +6) = r1 <-- further access based on .bss data
143: (b7) r1 = 108
144: (73) *(u8 *)(r8 +5) = r1
[...]
For Cilium use-case in particular, this enables migrating configuration
constants from Cilium daemon's generated header defines into global
data sections such that expensive runtime recompilations with LLVM can
be avoided altogether. Instead, the ELF file becomes effectively a
"template", meaning, it is compiled only once (!) and the Cilium daemon
will then rewrite relevant configuration data from the ELF's .data or
.rodata sections directly instead of recompiling the program. The
updated ELF is then loaded into the kernel and atomically replaces
the existing program in the networking datapath. More info in [0].
Based upon recent fix in LLVM, commit c0db6b6bd444 ("[BPF] Don't fail
for static variables").
[0] LPC 2018, BPF track, "ELF relocation for static data in BPF",
http://vger.kernel.org/lpc-bpf2018.html#session-3
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-09 23:20:13 +02:00
|
|
|
} LIBBPF_0.0.2;
|
2019-05-24 11:58:57 -07:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.4 {
|
|
|
|
|
global:
|
2019-07-01 16:58:56 -07:00
|
|
|
bpf_link__destroy;
|
|
|
|
|
bpf_object__load_xattr;
|
2019-07-01 16:58:58 -07:00
|
|
|
bpf_program__attach_kprobe;
|
2019-07-01 16:58:57 -07:00
|
|
|
bpf_program__attach_perf_event;
|
2019-07-01 16:59:00 -07:00
|
|
|
bpf_program__attach_raw_tracepoint;
|
2019-07-01 16:58:59 -07:00
|
|
|
bpf_program__attach_tracepoint;
|
2019-07-01 16:58:58 -07:00
|
|
|
bpf_program__attach_uprobe;
|
2019-05-24 11:59:03 -07:00
|
|
|
btf_dump__dump_type;
|
|
|
|
|
btf_dump__free;
|
|
|
|
|
btf_dump__new;
|
2019-05-24 11:58:57 -07:00
|
|
|
btf__parse_elf;
|
2019-06-10 17:56:50 -07:00
|
|
|
libbpf_num_possible_cpus;
|
2019-07-06 11:06:24 -07:00
|
|
|
perf_buffer__free;
|
|
|
|
|
perf_buffer__new;
|
|
|
|
|
perf_buffer__new_raw;
|
|
|
|
|
perf_buffer__poll;
|
2019-08-27 02:25:27 +00:00
|
|
|
xsk_umem__create;
|
2019-05-24 11:58:57 -07:00
|
|
|
} LIBBPF_0.0.3;
|
2019-08-14 13:05:48 -07:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.5 {
|
2019-08-20 10:31:53 +01:00
|
|
|
global:
|
|
|
|
|
bpf_btf_get_next_id;
|
2019-08-14 13:05:48 -07:00
|
|
|
} LIBBPF_0.0.4;
|
2019-09-30 15:25:03 -07:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.6 {
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 15:40:35 -07:00
|
|
|
global:
|
2019-11-09 21:37:31 +01:00
|
|
|
bpf_get_link_xdp_info;
|
2019-11-02 12:09:38 +01:00
|
|
|
bpf_map__get_pin_path;
|
|
|
|
|
bpf_map__is_pinned;
|
|
|
|
|
bpf_map__set_pin_path;
|
libbpf: add bpf_object__open_{file, mem} w/ extensible opts
Add new set of bpf_object__open APIs using new approach to optional
parameters extensibility allowing simpler ABI compatibility approach.
This patch demonstrates an approach to implementing libbpf APIs that
makes it easy to extend existing APIs with extra optional parameters in
such a way, that ABI compatibility is preserved without having to do
symbol versioning and generating lots of boilerplate code to handle it.
To facilitate succinct code for working with options, add OPTS_VALID,
OPTS_HAS, and OPTS_GET macros that hide all the NULL, size, and zero
checks.
Additionally, newly added libbpf APIs are encouraged to follow similar
pattern of having all mandatory parameters as formal function parameters
and always have optional (NULL-able) xxx_opts struct, which should
always have real struct size as a first field and the rest would be
optional parameters added over time, which tune the behavior of existing
API, if specified by user.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-10-04 15:40:35 -07:00
|
|
|
bpf_object__open_file;
|
|
|
|
|
bpf_object__open_mem;
|
2019-11-14 10:57:06 -08:00
|
|
|
bpf_program__attach_trace;
|
2019-10-20 20:38:57 -07:00
|
|
|
bpf_program__get_expected_attach_type;
|
|
|
|
|
bpf_program__get_type;
|
2019-10-30 15:32:12 -07:00
|
|
|
bpf_program__is_tracing;
|
|
|
|
|
bpf_program__set_tracing;
|
2019-11-09 21:37:32 +01:00
|
|
|
bpf_program__size;
|
2019-11-14 10:57:05 -08:00
|
|
|
btf__find_by_name_kind;
|
2019-11-14 10:57:06 -08:00
|
|
|
libbpf_find_vmlinux_btf_id;
|
2019-09-30 15:25:03 -07:00
|
|
|
} LIBBPF_0.0.5;
|
2019-12-09 14:40:22 -08:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.7 {
|
2019-12-13 17:43:26 -08:00
|
|
|
global:
|
2019-12-13 17:43:31 -08:00
|
|
|
btf_dump__emit_type_decl;
|
libbpf: Add bpf_link__disconnect() API to preserve underlying BPF resource
There are cases in which BPF resource (program, map, etc) has to outlive
userspace program that "installed" it in the system in the first place.
When BPF program is attached, libbpf returns bpf_link object, which
is supposed to be destroyed after no longer necessary through
bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic
detachment and frees up any resources allocated to for bpf_link in-memory
representation. This is inconvenient for the case described above because of
coupling of detachment and resource freeing.
This patch introduces bpf_link__disconnect() API call, which marks bpf_link as
disconnected from its underlying BPF resouces. This means that when bpf_link
is destroyed later, all its memory resources will be freed, but BPF resource
itself won't be detached.
This design allows to follow strict and resource-leak-free design by default,
while giving easy and straightforward way for user code to opt for keeping BPF
resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e.,
FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to
pin BPF program to prevent kernel to automatically detach it on process exit.
This should typically be achived by pinning BPF program (or map in some cases)
in BPF FS.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20191218225039.2668205-1-andriin@fb.com
2019-12-18 14:50:39 -08:00
|
|
|
bpf_link__disconnect;
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-08 16:35:14 -08:00
|
|
|
bpf_map__attach_struct_ops;
|
2020-01-15 10:43:06 -08:00
|
|
|
bpf_map_delete_batch;
|
|
|
|
|
bpf_map_lookup_and_delete_batch;
|
|
|
|
|
bpf_map_lookup_batch;
|
|
|
|
|
bpf_map_update_batch;
|
2019-12-13 17:43:32 -08:00
|
|
|
bpf_object__find_program_by_name;
|
2019-12-13 17:43:36 -08:00
|
|
|
bpf_object__attach_skeleton;
|
|
|
|
|
bpf_object__destroy_skeleton;
|
|
|
|
|
bpf_object__detach_skeleton;
|
|
|
|
|
bpf_object__load_skeleton;
|
|
|
|
|
bpf_object__open_skeleton;
|
2020-01-08 17:23:52 +01:00
|
|
|
bpf_probe_large_insn_limit;
|
2019-12-18 23:44:36 -08:00
|
|
|
bpf_prog_attach_xattr;
|
2019-12-13 17:43:26 -08:00
|
|
|
bpf_program__attach;
|
2019-12-13 17:43:32 -08:00
|
|
|
bpf_program__name;
|
2020-01-20 16:53:47 -08:00
|
|
|
bpf_program__is_extension;
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-08 16:35:14 -08:00
|
|
|
bpf_program__is_struct_ops;
|
2020-01-20 16:53:47 -08:00
|
|
|
bpf_program__set_extension;
|
bpf: libbpf: Add STRUCT_OPS support
This patch adds BPF STRUCT_OPS support to libbpf.
The only sec_name convention is SEC(".struct_ops") to identify the
struct_ops implemented in BPF,
e.g. To implement a tcp_congestion_ops:
SEC(".struct_ops")
struct tcp_congestion_ops dctcp = {
.init = (void *)dctcp_init, /* <-- a bpf_prog */
/* ... some more func prts ... */
.name = "bpf_dctcp",
};
Each struct_ops is defined as a global variable under SEC(".struct_ops")
as above. libbpf creates a map for each variable and the variable name
is the map's name. Multiple struct_ops is supported under
SEC(".struct_ops").
In the bpf_object__open phase, libbpf will look for the SEC(".struct_ops")
section and find out what is the btf-type the struct_ops is
implementing. Note that the btf-type here is referring to
a type in the bpf_prog.o's btf. A "struct bpf_map" is added
by bpf_object__add_map() as other maps do. It will then
collect (through SHT_REL) where are the bpf progs that the
func ptrs are referring to. No btf_vmlinux is needed in
the open phase.
In the bpf_object__load phase, the map-fields, which depend
on the btf_vmlinux, are initialized (in bpf_map__init_kern_struct_ops()).
It will also set the prog->type, prog->attach_btf_id, and
prog->expected_attach_type. Thus, the prog's properties do
not rely on its section name.
[ Currently, the bpf_prog's btf-type ==> btf_vmlinux's btf-type matching
process is as simple as: member-name match + btf-kind match + size match.
If these matching conditions fail, libbpf will reject.
The current targeting support is "struct tcp_congestion_ops" which
most of its members are function pointers.
The member ordering of the bpf_prog's btf-type can be different from
the btf_vmlinux's btf-type. ]
Then, all obj->maps are created as usual (in bpf_object__create_maps()).
Once the maps are created and prog's properties are all set,
the libbpf will proceed to load all the progs.
bpf_map__attach_struct_ops() is added to register a struct_ops
map to a kernel subsystem.
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200109003514.3856730-1-kafai@fb.com
2020-01-08 16:35:14 -08:00
|
|
|
bpf_program__set_struct_ops;
|
2019-12-13 17:43:30 -08:00
|
|
|
btf__align_of;
|
2020-01-15 15:00:31 -08:00
|
|
|
libbpf_find_kernel_btf;
|
2019-12-09 14:40:22 -08:00
|
|
|
} LIBBPF_0.0.6;
|
2020-02-20 13:26:24 +00:00
|
|
|
|
|
|
|
|
LIBBPF_0.0.8 {
|
2020-02-20 13:26:35 +00:00
|
|
|
global:
|
libbpf: Add bpf_link pinning/unpinning
With bpf_link abstraction supported by kernel explicitly, add
pinning/unpinning API for links. Also allow to create (open) bpf_link from BPF
FS file.
This API allows to have an "ephemeral" FD-based BPF links (like raw tracepoint
or fexit/freplace attachments) surviving user process exit, by pinning them in
a BPF FS, which is an important use case for long-running BPF programs.
As part of this, expose underlying FD for bpf_link. While legacy bpf_link's
might not have a FD associated with them (which will be expressed as
a bpf_link with fd=-1), kernel's abstraction is based around FD-based usage,
so match it closely. This, subsequently, allows to have a generic
pinning/unpinning API for generalized bpf_link. For some types of bpf_links
kernel might not support pinning, in which case bpf_link__pin() will return
error.
With FD being part of generic bpf_link, also get rid of bpf_link_fd in favor
of using vanialla bpf_link.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200303043159.323675-3-andriin@fb.com
2020-03-02 20:31:58 -08:00
|
|
|
bpf_link__fd;
|
|
|
|
|
bpf_link__open;
|
|
|
|
|
bpf_link__pin;
|
|
|
|
|
bpf_link__pin_path;
|
|
|
|
|
bpf_link__unpin;
|
2020-03-29 15:22:52 +02:00
|
|
|
bpf_map__set_initial_value;
|
2020-02-20 13:26:35 +00:00
|
|
|
bpf_program__set_attach_target;
|
2020-03-25 18:23:28 +01:00
|
|
|
bpf_set_link_xdp_fd_opts;
|
2020-02-20 13:26:24 +00:00
|
|
|
} LIBBPF_0.0.7;
|