20 Mar, 2020
4 commits
-
This patch adds struct_ops support to the bpftool.
To recap a bit on the recent bpf_struct_ops feature on the kernel side:
It currently supports "struct tcp_congestion_ops" to be implemented
in bpf. At a high level, bpf_struct_ops is struct_ops map populated
with a number of bpf progs. bpf_struct_ops currently supports the
"struct tcp_congestion_ops". However, the bpf_struct_ops design is
generic enough that other kernel struct ops can be supported in
the future.Although struct_ops is map+progs at a high lever, there are differences
in details. For example,
1) After registering a struct_ops, the struct_ops is held by the kernel
subsystem (e.g. tcp-cc). Thus, there is no need to pin a
struct_ops map or its progs in order to keep them around.
2) To iterate all struct_ops in a system, it iterates all maps
in type BPF_MAP_TYPE_STRUCT_OPS. BPF_MAP_TYPE_STRUCT_OPS is
the current usual filter. In the future, it may need to
filter by other struct_ops specific properties. e.g. filter by
tcp_congestion_ops or other kernel subsystem ops in the future.
3) struct_ops requires the running kernel having BTF info. That allows
more flexibility in handling other kernel structs. e.g. it can
always dump the latest bpf_map_info.
4) Also, "struct_ops" command is not intended to repeat all features
already provided by "map" or "prog". For example, if there really
is a need to pin the struct_ops map, the user can use the "map" cmd
to do that.While the first attempt was to reuse parts from map/prog.c, it ended up
not a lot to share. The only obvious item is the map_parse_fds() but
that still requires modifications to accommodate struct_ops map specific
filtering (for the immediate and the future needs). Together with the
earlier mentioned differences, it is better to part away from map/prog.c.The initial set of subcmds are, register, unregister, show, and dump.
For register, it registers all struct_ops maps that can be found in an
obj file. Option can be added in the future to specify a particular
struct_ops map. Also, the common bpf_tcp_cc is stateless (e.g.
bpf_cubic.c and bpf_dctcp.c). The "reuse map" feature is not
implemented in this patch and it can be considered later also.For other subcmds, please see the man doc for details.
A sample output of dump:
[root@arch-fb-vm1 bpf]# bpftool struct_ops dump name cubic
[{
"bpf_map_info": {
"type": 26,
"id": 64,
"key_size": 4,
"value_size": 256,
"max_entries": 1,
"map_flags": 0,
"name": "cubic",
"ifindex": 0,
"btf_vmlinux_value_type_id": 18452,
"netns_dev": 0,
"netns_ino": 0,
"btf_id": 52,
"btf_key_type_id": 0,
"btf_value_type_id": 0
}
},{
"bpf_struct_ops_tcp_congestion_ops": {
"refcnt": {
"refs": {
"counter": 1
}
},
"state": "BPF_STRUCT_OPS_STATE_INUSE",
"data": {
"list": {
"next": 0,
"prev": 0
},
"key": 0,
"flags": 0,
"init": "void (struct sock *) bictcp_init/prog_id:138",
"release": "void (struct sock *) 0",
"ssthresh": "u32 (struct sock *) bictcp_recalc_ssthresh/prog_id:141",
"cong_avoid": "void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140",
"set_state": "void (struct sock *, u8) bictcp_state/prog_id:142",
"cwnd_event": "void (struct sock *, enum tcp_ca_event) bictcp_cwnd_event/prog_id:139",
"in_ack_event": "void (struct sock *, u32) 0",
"undo_cwnd": "u32 (struct sock *) tcp_reno_undo_cwnd/prog_id:144",
"pkts_acked": "void (struct sock *, const struct ack_sample *) bictcp_acked/prog_id:143",
"min_tso_segs": "u32 (struct sock *) 0",
"sndbuf_expand": "u32 (struct sock *) 0",
"cong_control": "void (struct sock *, const struct rate_sample *) 0",
"get_info": "size_t (struct sock *, u32, int *, union tcp_cc_info *) 0",
"name": "bpf_cubic",
"owner": 0
}
}
}
]Signed-off-by: Martin KaFai Lau
Signed-off-by: Daniel Borkmann
Acked-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200318171656.129650-1-kafai@fb.com -
The kernel struct_ops obj has kernel's func ptrs implemented by bpf_progs.
The bpf prog_id is stored as the value of the func ptr for introspection
purpose. In the latter patch, a struct_ops dump subcmd will be added
to introspect these func ptrs. It is desired to print the actual bpf
prog_name instead of only printing the prog_id.Since struct_ops is the only usecase storing prog_id in the func ptr,
this patch adds a prog_id_as_func_ptr bool (default is false) to
"struct btf_dumper" in order not to mis-interpret the ptr value
for the other existing use-cases.While printing a func_ptr as a bpf prog_name,
this patch also prefix the bpf prog_name with the ptr's func_proto.
[ Note that it is the ptr's func_proto instead of the bpf prog's
func_proto ]
It reuses the current btf_dump_func() to obtain the ptr's func_proto
string.Here is an example from the bpf_cubic.c:
"void (struct sock *, u32, u32) bictcp_cong_avoid/prog_id:140"Signed-off-by: Martin KaFai Lau
Signed-off-by: Daniel Borkmann
Acked-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200318171650.129252-1-kafai@fb.com -
A char[] is currently printed as an integer array.
This patch will print it as a string when
1) The array element type is an one byte int
2) The array element type has a BTF_INT_CHAR encoding or
the array element type's name is "char"
3) All characters is between (0x1f, 0x7f) and it is terminated
by a null character.Signed-off-by: Martin KaFai Lau
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Acked-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200318171643.129021-1-kafai@fb.com -
This patch prints the enum's name if there is one found in
the array of btf_enum.The commit 9eea98497951 ("bpf: fix BTF verification of enums")
has details about an enum could have any power-of-2 size (up to 8 bytes).
This patch also takes this chance to accommodate these non 4 byte
enums.Signed-off-by: Martin KaFai Lau
Signed-off-by: Daniel Borkmann
Acked-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200318171637.128862-1-kafai@fb.com
14 Mar, 2020
2 commits
-
Commit fe4eb069edb7 ("bpftool: Use linux/types.h from source tree for
profiler build") added a build dependency on tools/testing/selftests/bpf
to tools/bpf/bpftool. This is suboptimal with respect to a possible
stand-alone build of bpftool.Fix this by moving tools/testing/selftests/bpf/include/uapi/linux/types.h
to tools/include/uapi/linux/types.h.This requires an adjustment in the include search path order for the
tests in tools/testing/selftests/bpf so that tools/include/linux/types.h
is selected when building host binaries and
tools/include/uapi/linux/types.h is selected when building bpf binaries.Verified by compiling bpftool and the bpf selftests on x86_64 with this
change.Fixes: fe4eb069edb7 ("bpftool: Use linux/types.h from source tree for profiler build")
Suggested-by: Andrii Nakryiko
Signed-off-by: Tobias Klauser
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200313113105.6918-1-tklauser@distanz.ch -
In commit 4a3d6c6a6e4d ("libbpf: Reduce log level for custom section
names"), log level for messages for libbpf_attach_type_by_name() and
libbpf_prog_type_by_name() was downgraded from "info" to "debug". The
latter function, in particular, is used by bpftool when attempting to
load programs, and this change caused bpftool to exit with no hint or
error message when it fails to detect the type of the program to load
(unless "-d" option was provided).To help users understand why bpftool fails to load the program, let's do
a second run of the function with log level in "debug" mode in case of
failure.Before:
# bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
# echo $?
255Or really verbose with -d flag:
# bpftool -d prog load sample_ret0.o /sys/fs/bpf/sample_ret0
libbpf: loading sample_ret0.o
libbpf: section(1) .strtab, size 134, link 0, flags 0, type=3
libbpf: skip section(1) .strtab
libbpf: section(2) .text, size 16, link 0, flags 6, type=1
libbpf: found program .text
libbpf: section(3) .debug_abbrev, size 55, link 0, flags 0, type=1
libbpf: skip section(3) .debug_abbrev
libbpf: section(4) .debug_info, size 75, link 0, flags 0, type=1
libbpf: skip section(4) .debug_info
libbpf: section(5) .rel.debug_info, size 32, link 14, flags 0, type=9
libbpf: skip relo .rel.debug_info(5) for section(4)
libbpf: section(6) .debug_str, size 150, link 0, flags 30, type=1
libbpf: skip section(6) .debug_str
libbpf: section(7) .BTF, size 155, link 0, flags 0, type=1
libbpf: section(8) .BTF.ext, size 80, link 0, flags 0, type=1
libbpf: section(9) .rel.BTF.ext, size 32, link 14, flags 0, type=9
libbpf: skip relo .rel.BTF.ext(9) for section(8)
libbpf: section(10) .debug_frame, size 40, link 0, flags 0, type=1
libbpf: skip section(10) .debug_frame
libbpf: section(11) .rel.debug_frame, size 16, link 14, flags 0, type=9
libbpf: skip relo .rel.debug_frame(11) for section(10)
libbpf: section(12) .debug_line, size 74, link 0, flags 0, type=1
libbpf: skip section(12) .debug_line
libbpf: section(13) .rel.debug_line, size 16, link 14, flags 0, type=9
libbpf: skip relo .rel.debug_line(13) for section(12)
libbpf: section(14) .symtab, size 96, link 1, flags 0, type=2
libbpf: looking for externs among 4 symbols...
libbpf: collected 0 externs total
libbpf: failed to guess program type from ELF section '.text'
libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]After:
# bpftool prog load sample_ret0.o /sys/fs/bpf/sample_ret0
libbpf: failed to guess program type from ELF section '.text'
libbpf: supported section(type) names are: socket sk_reuseport kprobe/ [...]Signed-off-by: Quentin Monnet
Signed-off-by: Alexei Starovoitov
Acked-by: John Fastabend
Link: https://lore.kernel.org/bpf/20200311021205.9755-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov
13 Mar, 2020
5 commits
-
Minor fixes for bash completion: addition of program name completion for
two subcommands, and correction for program test-runs and map pinning.The completion for the following commands is fixed or improved:
# bpftool prog run [TAB]
# bpftool prog pin [TAB]
# bpftool map pin [TAB]
# bpftool net attach xdp name [TAB]Signed-off-by: Quentin Monnet
Signed-off-by: Daniel Borkmann
Acked-by: Martin KaFai Lau
Link: https://lore.kernel.org/bpf/20200312184608.12050-3-quentin@isovalent.com -
Documentation and interactive help for bpftool have always explained
that the regular handles for programs (id|name|tag|pinned) and maps
(id|name|pinned) can be passed to the utility when attempting to pin
objects (bpftool prog pin PROG / bpftool map pin MAP).THIS IS A LIE!! The tool actually accepts only ids, as the parsing is
done in do_pin_any() in common.c instead of reusing the parsing
functions that have long been generic for program and map handles.Instead of fixing the doc, fix the code. It is trivial to reuse the
generic parsing, and to simplify do_pin_any() in the process.Do not accept to pin multiple objects at the same time with
prog_parse_fds() or map_parse_fds() (this would require a more complex
syntax for passing multiple sysfs paths and validating that they
correspond to the number of e.g. programs we find for a given name or
tag).Signed-off-by: Quentin Monnet
Signed-off-by: Daniel Borkmann
Acked-by: Martin KaFai Lau
Link: https://lore.kernel.org/bpf/20200312184608.12050-2-quentin@isovalent.com -
These files are generated, so ignore them.
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200312182332.3953408-4-songliubraving@fb.com -
Add the dependency to libbpf, to fix build errors like:
In file included from skeleton/profiler.bpf.c:5:
.../bpf_helpers.h:5:10: fatal error: 'bpf_helper_defs.h' file not found
#include "bpf_helper_defs.h"
^~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [skeleton/profiler.bpf.o] Error 1
make: *** Waiting for unfinished jobs....Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Suggested-by: Quentin Monnet
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Acked-by: John Fastabend
Link: https://lore.kernel.org/bpf/20200312182332.3953408-3-songliubraving@fb.com -
bpftool-prog-profile requires clang to generate BTF for global variables.
When compared with older clang, skip this command. This is achieved by
adding a new feature, clang-bpf-global-var, to tools/build/feature.Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200312182332.3953408-2-songliubraving@fb.com
12 Mar, 2020
1 commit
-
When compiling bpftool on a system where the /usr/include/asm symlink
doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed),
the build fails with:CLANG skeleton/profiler.bpf.o
In file included from skeleton/profiler.bpf.c:4:
In file included from /usr/include/linux/bpf.h:11:
/usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
#include
^~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1This indicates that the build is using linux/types.h from system headers
instead of source tree headers.To fix this, adjust the clang search path to include the necessary
headers from tools/testing/selftests/bpf/include/uapi and
tools/include/uapi. Also use __bitwise__ instead of __bitwise in
skeleton/profiler.h to avoid clashing with the definition in
tools/testing/selftests/bpf/include/uapi/linux/types.h.Signed-off-by: Tobias Klauser
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200312130330.32239-1-tklauser@distanz.ch
11 Mar, 2020
1 commit
-
Libbpf compiles and runs subset of selftests on each PR in its Github mirror
repository. To allow still building up-to-date selftests against outdated
kernel images, add back BPF_F_CURRENT_CPU definitions back.N.B. BCC's runqslower version ([0]) doesn't need BPF_F_CURRENT_CPU due to use of
locally checked in vmlinux.h, generated against kernel with 1aae4bdd7879 ("bpf:
Switch BPF UAPI #define constants used from BPF program side to enums")
applied.[0] https://github.com/iovisor/bcc/pull/2809
Fixes: 367d82f17eff (" tools/runqslower: Drop copy/pasted BPF_F_CURRENT_CPU definiton")
Signed-off-by: Andrii Nakryiko
Signed-off-by: Daniel Borkmann
Link: https://lore.kernel.org/bpf/20200311043010.530620-1-andriin@fb.com
10 Mar, 2020
4 commits
-
_bpftool_get_map_names => _bpftool_get_prog_names for prog-attach|detach.
Fixes: 99f9863a0c45 ("bpftool: Match maps by name")
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200309173218.2739965-5-songliubraving@fb.com -
Add bash completion for "bpftool prog profile" command.
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200309173218.2739965-4-songliubraving@fb.com -
Add documentation for the new bpftool prog profile command.
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200309173218.2739965-3-songliubraving@fb.com -
With fentry/fexit programs, it is possible to profile BPF program with
hardware counters. Introduce bpftool "prog profile", which measures key
metrics of a BPF program.bpftool prog profile command creates per-cpu perf events. Then it attaches
fentry/fexit programs to the target BPF program. The fentry program saves
perf event value to a map. The fexit program reads the perf event again,
and calculates the difference, which is the instructions/cycles used by
the target program.Example input and output:
./bpftool prog profile id 337 duration 3 cycles instructions llc_misses
4228 run_cnt
3403698 cycles (84.08%)
3525294 instructions # 1.04 insn per cycle (84.05%)
13 llc_misses # 3.69 LLC misses per million isns (83.50%)This command measures cycles and instructions for BPF program with id
337 for 3 seconds. The program has triggered 4228 times. The rest of the
output is similar to perf-stat. In this example, the counters were only
counting ~84% of the time because of time multiplexing of perf counters.Note that, this approach measures cycles and instructions in very small
increments. So the fentry/fexit programs introduce noticeable errors to
the measurement results.The fentry/fexit programs are generated with BPF skeletons. Therefore, we
build bpftool twice. The first time _bpftool is built without skeletons.
Then, _bpftool is used to generate the skeletons. The second time, bpftool
is built with skeletons.Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Acked-by: Yonghong Song
Link: https://lore.kernel.org/bpf/20200309173218.2739965-2-songliubraving@fb.com
05 Mar, 2020
1 commit
-
With BPF_F_CURRENT_CPU being an enum, it is now captured in vmlinux.h and is
readily usable by runqslower. So drop local copy/pasted definition in favor of
the one coming from vmlinux.h.Signed-off-by: Andrii Nakryiko
Signed-off-by: Daniel Borkmann
Link: https://lore.kernel.org/bpf/20200303003233.3496043-4-andriin@fb.com
03 Mar, 2020
1 commit
-
Add canonical #ifndef/#define/#endif guard for generated vmlinux.h header with
__VMLINUX_H__ symbol. __VMLINUX_H__ is also going to play double role of
identifying whether vmlinux.h is being used, versus, say, BCC or non-CO-RE
libbpf modes with dependency on kernel headers. This will make it possible to
write helper macro/functions, agnostic to exact BPF program set up.Signed-off-by: Andrii Nakryiko
Signed-off-by: Alexei Starovoitov
Link: https://lore.kernel.org/bpf/20200229231112.1240137-2-andriin@fb.com
27 Feb, 2020
4 commits
-
Update bash completion for "bpftool feature" command with the new
argument: "full".Signed-off-by: Michal Rostecki
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200226165941.6379-5-mrostecki@opensuse.org -
Update documentation of "bpftool feature" command with information about
new arguments: "full".Signed-off-by: Michal Rostecki
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200226165941.6379-4-mrostecki@opensuse.org -
Probes related to bpf_probe_write_user and bpf_trace_printk helpers emit
dmesg warnings which might be confusing for people running bpftool on
production environments. This change filters them out by default and
introduces the new positional argument "full" which enables all
available probes.Signed-off-by: Michal Rostecki
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200226165941.6379-3-mrostecki@opensuse.org -
Remove all calls of print_end_then_start_section function and for loops
out from the do_probe function. Instead, provide separate functions for
each section (like i.e. section_helpers) which are called in do_probe.
This change is motivated by better readability.Signed-off-by: Michal Rostecki
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200226165941.6379-2-mrostecki@opensuse.org
26 Feb, 2020
1 commit
-
Add support for prog types that were added to kernel but not present in
bpftool yet: struct_ops, tracing, ext prog types and corresponding
section names.Before:
# bpftool p l
...
184: type 26 name test_subprog3 tag dda135a7dc0daf54 gpl
loaded_at 2020-02-25T13:28:33-0800 uid 0
xlated 112B jited 103B memlock 4096B map_ids 136
btf_id 85
185: type 28 name new_get_skb_len tag d2de5b87d8e5dc49 gpl
loaded_at 2020-02-25T13:28:33-0800 uid 0
xlated 72B jited 69B memlock 4096B map_ids 136
btf_id 85After:
# bpftool p l
...
184: tracing name test_subprog3 tag dda135a7dc0daf54 gpl
loaded_at 2020-02-25T13:28:33-0800 uid 0
xlated 112B jited 103B memlock 4096B map_ids 136
btf_id 85
185: ext name new_get_skb_len tag d2de5b87d8e5dc49 gpl
loaded_at 2020-02-25T13:28:33-0800 uid 0
xlated 72B jited 69B memlock 4096B map_ids 136
btf_id 85Signed-off-by: Andrey Ignatov
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Acked-by: Song Liu
Link: https://lore.kernel.org/bpf/20200225223441.689109-1-rdna@fb.com
08 Feb, 2020
1 commit
-
Turns out the xlated program instructions can also be missing if
kptr_restrict sysctl is set. This means that the previous fix to check the
jited_prog_insns pointer was insufficient; add another check of the
xlated_prog_insns pointer as well.Fixes: 5b79bcdf0362 ("bpftool: Don't crash on missing jited insns or ksyms")
Fixes: cae73f233923 ("bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump()")
Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Link: https://lore.kernel.org/bpf/20200206102906.112551-1-toke@redhat.com
06 Feb, 2020
1 commit
-
Add missing dependency of $(BPFOBJ) to $(LIBBPF_SRC), so that running make
in runqslower/ will rebuild libbpf.a when there is change in libbpf/.Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf")
Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200204215037.2258698-1-songliubraving@fb.com
04 Feb, 2020
1 commit
-
"HAVE" prefix is already applied by default to feature macros and before
this change, the large INSN limit macro had the incorrect name with
double "HAVE".Fixes: 2faef64aa6b3 ("bpftool: Add misc section and probe for large INSN limit")
Signed-off-by: Michal Rostecki
Signed-off-by: Daniel Borkmann
Acked-by: Yonghong Song
Link: https://lore.kernel.org/bpf/20200202110200.31024-1-mrostecki@opensuse.org
31 Jan, 2020
1 commit
-
Fix undefined reference linker errors when building runqslower with
gcc 7.4.0 on Ubuntu 18.04.
The issue is with misplaced -lelf, -lz options in Makefile:
$(Q)$(CC) $(CFLAGS) -lelf -lz $^ -o $@-lelf, -lz options should follow the list of target dependencies:
$(Q)$(CC) $(CFLAGS) $^ -lelf -lz -o $@
or after substitution
cc -g -Wall runqslower.o libbpf.a -lelf -lz -o runqslowerThe current order of gcc params causes failure in libelf symbols resolution,
e.g. undefined reference to `elf_memory'Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf")
Signed-off-by: Julia Kartseva
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com
27 Jan, 2020
1 commit
-
tools/testing/selftests/bpf/Makefile supports overriding clang, llc and
other tools so that custom ones can be used instead of those from PATH.
It's convinient and heavily used by some users.Apply same rules to runqslower/Makefile.
Signed-off-by: Andrey Ignatov
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200124224142.1833678-1-rdna@fb.com
24 Jan, 2020
1 commit
-
Add printing out BTF_KIND_FUNC's linkage.
Signed-off-by: Andrii Nakryiko
Signed-off-by: Daniel Borkmann
Acked-by: Martin KaFai Lau
Acked-by: Toke Høiland-Jørgensen
Link: https://lore.kernel.org/bpf/20200124054317.2459436-1-andriin@fb.com
23 Jan, 2020
1 commit
-
Alexei Starovoitov says:
====================
pull-request: bpf-next 2020-01-22The following pull-request contains BPF updates for your *net-next* tree.
We've added 92 non-merge commits during the last 16 day(s) which contain
a total of 320 files changed, 7532 insertions(+), 1448 deletions(-).The main changes are:
1) function by function verification and program extensions from Alexei.
2) massive cleanup of selftests/bpf from Toke and Andrii.
3) batched bpf map operations from Brian and Yonghong.
4) tcp congestion control in bpf from Martin.
5) bulking for non-map xdp_redirect form Toke.
6) bpf_send_signal_thread helper from Yonghong.
====================Signed-off-by: David S. Miller
21 Jan, 2020
5 commits
-
This adds support for specifying the libbpf include and object paths as
arguments to the runqslower Makefile, to support reusing the libbpf version
built as part of the selftests.Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Alexei Starovoitov
Link: https://lore.kernel.org/bpf/157952561135.1683545.5660339645093141381.stgit@toke.dk -
Since we are now consistently using the bpf/ prefix on #include directives,
we don't need to include tools/lib/bpf in the include path. Remove it to
make sure we don't inadvertently introduce new includes without the prefix.Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/157952561027.1683545.1976265477926794138.stgit@toke.dk -
Fix bpftool to include libbpf header files with the bpf/ prefix, to be
consistent with external users of the library. Also ensure that all
includes of exported libbpf header files (those that are exported on 'make
install' of the library) use bracketed includes instead of quoted.To make sure no new files are introduced that doesn't include the bpf/
prefix in its include, remove tools/lib/bpf from the include path entirely,
and use tools/lib instead.Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir")
Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/157952560684.1683545.4765181397974997027.stgit@toke.dk -
Fix the runqslower tool to include libbpf header files with the bpf/
prefix, to be consistent with external users of the library. Also ensure
that all includes of exported libbpf header files (those that are exported
on 'make install' of the library) use bracketed includes instead of quoted.To not break the build, keep the old include path until everything has been
changed to the new one; a subsequent patch will remove that.Fixes: 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are taken from selftests dir")
Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/157952560457.1683545.9913736511685743625.stgit@toke.dk -
The runqslower tool refuses to build without a file to read vmlinux BTF
from. The build fails with an error message to override the location by
setting the VMLINUX_BTF variable if autodetection fails. However, the
Makefile doesn't actually work with that override - the error message is
still emitted.Fix this by including the value of VMLINUX_BTF in the expansion, and only
emitting the error message if the *result* is empty. Also permit running
'make clean' even though no VMLINUX_BTF is set.Fixes: 9c01546d26d2 ("tools/bpf: Add runqslower tool to tools/bpf")
Signed-off-by: Toke Høiland-Jørgensen
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/157952560237.1683545.17771785178857224877.stgit@toke.dk
20 Jan, 2020
1 commit
16 Jan, 2020
3 commits
-
This patch makes bpftool support dumping a map's value properly
when the map's value type is a type of the running kernel's btf.
(i.e. map_info.btf_vmlinux_value_type_id is set instead of
map_info.btf_value_type_id). The first usecase is for the
BPF_MAP_TYPE_STRUCT_OPS.Signed-off-by: Martin KaFai Lau
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200115230044.1103008-1-kafai@fb.com -
This patch adds BPF_MAP_TYPE_STRUCT_OPS to "struct_ops" name mapping
so that "bpftool map show" can print the "struct_ops" map type
properly.[root@arch-fb-vm1 bpf]# ~/devshare/fb-kernel/linux/tools/bpf/bpftool/bpftool map show id 8
8: struct_ops name dctcp flags 0x0
key 4B value 256B max_entries 1 memlock 4096B
btf_id 7Signed-off-by: Martin KaFai Lau
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200115230037.1102674-1-kafai@fb.com -
The btf availability check is only done for plain text output.
It causes the whole BTF output went missing when json_output
is used.This patch simplifies the logic a little by avoiding passing "int btf" to
map_dump().For plain text output, the btf_wtr is only created when the map has
BTF (i.e. info->btf_id != 0). The nullness of "json_writer_t *wtr"
in map_dump() alone can decide if dumping BTF output is needed.
As long as wtr is not NULL, map_dump() will print out the BTF-described
data whenever a map has BTF available (i.e. info->btf_id != 0)
regardless of json or plain-text output.In do_dump(), the "int btf" is also renamed to "int do_plain_btf".
Fixes: 99f9863a0c45 ("bpftool: Match maps by name")
Signed-off-by: Martin KaFai Lau
Signed-off-by: Alexei Starovoitov
Acked-by: Andrii Nakryiko
Cc: Paul Chaignon
Link: https://lore.kernel.org/bpf/20200115230025.1101828-1-kafai@fb.com