linux/tools/bpf, branch v5.0

tools: bpftool: fix crash with un-owned prog arrays

2019-01-28T22:59:46Z

Prog arrays don't have 'owner_prog_type' and 'owner_jited' fields in their fdinfo when they are created. Those fields are set and reported when first program is checked for compatibility by bpf_prog_array_compatible(). This means that bpftool cannot expect the fields to always be there. Currently trying to show maps on a system with an un-owned prog array leads to a crash: $ bpftool map show 389: prog_array name tail_call_map flags 0x0 Error: key 'owner_prog_type' not found in fdinfo Error: key 'owner_jited' not found in fdinfo key 4B value 4B max_entries 4 memlock 4096B Segmentation fault (core dumped) We pass a NULL pointer to atoi(). Remove the assumption that fdinfo keys are always present. Add missing validations and remove the p_err() calls which may lead to broken JSON output as caller will not propagate the failure. Fixes: 99a44bef5870 ("tools: bpftool: add owner_prog_type and owner_jited to bpftool output") Signed-off-by: Jakub Kicinski Reviewed-by: Quentin Monnet Acked-by: Song Liu Signed-off-by: Daniel Borkmann

bpftool: fix percpu maps updating

2019-01-23T08:56:20Z

When updating a percpu map, bpftool currently copies the provided value only into the first per CPU copy of the specified value, all others instances are left zeroed. This change explicitly copies the user-provided bytes to all the per CPU instances, keeping the sub-command syntax unchanged. v2 -> v3: - drop unused argument, as per Quentin's suggestion v1 -> v2: - rename the helper as per Quentin's suggestion Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Signed-off-by: Paolo Abeni Reviewed-by: Quentin Monnet Signed-off-by: Daniel Borkmann

bpftool: Fix prog dump by tag

2019-01-23T08:52:12Z

Lance reported an issue with bpftool not being able to dump program if there are more programs loaded and you want to dump any but the first program, like: # bpftool prog 28: kprobe name trace_req_start tag 1dfc28ba8b3dd597 gpl loaded_at 2019-01-18T17:02:40+1100 uid 0 xlated 112B jited 109B memlock 4096B map_ids 13 29: kprobe name trace_req_compl tag 5b6a5ecc6030a683 gpl loaded_at 2019-01-18T17:02:40+1100 uid 0 xlated 928B jited 575B memlock 4096B map_ids 13,14 # bpftool prog dum jited tag 1dfc28ba8b3dd597 0: push %rbp 1: mov %rsp,%rbp ... # bpftool prog dum jited tag 5b6a5ecc6030a683 Error: can't get prog info (29): Bad address The problem is in the prog_fd_by_tag function not cleaning the struct bpf_prog_info before another request, so the previous program length is still in there and kernel assumes it needs to dump the program, which fails because there's no user pointer set. Moving the struct bpf_prog_info declaration into the loop, so it gets cleaned before each query. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Reported-by: Lance Digby Signed-off-by: Jiri Olsa Reviewed-by: Quentin Monnet Acked-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools: bpftool: Cleanup license mess

2019-01-18T23:26:54Z

Precise and non-ambiguous license information is important. The recent relicensing of the bpftools introduced a license conflict. The files have now: SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause and * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version Amazingly about 20 people acked that change and neither they nor the committer noticed. Oh well. Digging deeper: The files were imported from the iproute2 repository with the GPL V2 or later boiler plate text in commit b66e907cfee2 ("tools: bpftool: copy JSON writer from iproute2 repository") Looking at the iproute2 repository at git://git.kernel.org/pub/scm/network/iproute2/iproute2.git the following commit is the equivivalent: commit d9d8c839 ("json_writer: add SPDX Identifier (GPL-2/BSD-2)") That commit explicitly removes the boiler plate and relicenses the code uner GPL-2.0-only and BSD-2-Clause. As Steven wrote the original code and also the relicensing commit, it's assumed that the relicensing was intended to do exaclty that. Just the kernel side update failed to remove the boiler plate. Do so now. Fixes: 907b22365115 ("tools: bpftool: dual license all files") Signed-off-by: Thomas Gleixner Cc: Jakub Kicinski Cc: Roman Gushchin Cc: YueHaibing Cc: Yonghong Song Cc: Stanislav Fomichev Cc: Sean Young Cc: Jiri Benc Cc: David Calavera Cc: Andrey Ignatov Cc: Joe Stringer Cc: David Ahern Cc: Alexei Starovoitov Cc: Petar Penkov Cc: Sandipan Das Cc: Prashant Bhole Cc: Stephen Hemminger Cc: John Fastabend Cc: Taeung Song Cc: Jiri Olsa Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Quentin Monnet CC: okash.khawaja@gmail.com Cc: netdev@vger.kernel.org Acked-by: Jakub Kicinski Signed-off-by: Alexei Starovoitov

tools/bpf: properly account for libbfd variations

2019-01-15T23:53:48Z

On some platforms, in order to link against libbfd, we need to link against liberty and even possibly libz. Account for that in the bpftool Makefile. We now have proper feature detection for each case, so handle each one separately. See recent commit 14541b1e7e72 ("perf build: Don't unconditionally link the libbfd feature test to -liberty and -lz") where I fixed feature detection. v2 (addressed Jakub's nits): * better syntax for 'else ifeq' * no space between ifeq args v3: * use LIBS, not EXTLIBS for -DHAVE_LIBBFD_SUPPORT Fixes: 29a9c10e4110 ("bpftool: make libbfd optional") Signed-off-by: Stanislav Fomichev Acked-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools/bpf: fix bpftool map dump with bitfields

2019-01-11T09:40:54Z

Commit 8772c8bc093b ("tools: bpftool: support pretty print with kind_flag set") added bpftool map dump with kind_flag support. When bitfield_size can be retrieved directly from btf_member, function btf_dumper_bitfield() is called to dump the bitfield. The implementation passed the wrong parameter "bit_offset" to the function. The excepted value is the bit_offset within a byte while the passed-in value is the struct member offset. This commit fixed the bug with passing correct "bit_offset" with adjusted data pointer. Fixes: 8772c8bc093b ("tools: bpftool: support pretty print with kind_flag set") Acked-by: Martin KaFai Lau Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann

tools: bpftool: do not force gcc as CC

2018-12-19T20:57:25Z

This allows transparent cross-compilation with CROSS_COMPILE by relying on 7ed1c1901fe5 ("tools: fix cross-compile var clobbering"). Signed-off-by: Ivan Babrou Signed-off-by: Daniel Borkmann

tools: bpftool: add an option to prevent auto-mount of bpffs, tracefs

2018-12-18T13:47:17Z

In order to make life easier for users, bpftool automatically attempts to mount the BPF virtual file system, if it is not mounted already, before trying to pin objects in it. Similarly, it attempts to mount tracefs if necessary before trying to dump the trace pipe to the console. While mounting file systems on-the-fly can improve user experience, some administrators might prefer to avoid that. Let's add an option to block these mount attempts. Note that it does not prevent automatic mounting of tracefs by debugfs for the "bpftool prog tracelog" command. Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools: bpftool: attempt to mount tracefs if required for tracelog cmd

2018-12-18T13:47:17Z

As a follow-up to commit 30da46b5dc3a ("tools: bpftool: add a command to dump the trace pipe"), attempt to mount the tracefs virtual file system if it is not detected on the system before trying to dump content of the tracing pipe on an invocation of "bpftool prog tracelog". Usually, tracefs in automatically mounted by debugfs when the user tries to access it (e.g. "ls /sys/kernel/debug/tracing" mounts the tracefs). So if we failed to find it, it is probably that debugfs is not here either. Therefore, we just attempt a single mount, at a location that does not involve debugfs: /sys/kernel/tracing. Suggested-by: Daniel Borkmann Signed-off-by: Quentin Monnet Reviewed-by: Jakub Kicinski Signed-off-by: Daniel Borkmann

tools: bpftool: support pretty print with kind_flag set

2018-12-18T00:12:00Z

The following example shows map pretty print with structures which include bitfield members. enum A { A1, A2, A3, A4, A5 }; typedef enum A ___A; struct tmp_t { char a1:4; int a2:4; int :4; __u32 a3:4; int b; ___A b1:4; enum A b2:4; }; struct bpf_map_def SEC("maps") tmpmap = { .type = BPF_MAP_TYPE_ARRAY, .key_size = sizeof(__u32), .value_size = sizeof(struct tmp_t), .max_entries = 1, }; BPF_ANNOTATE_KV_PAIR(tmpmap, int, struct tmp_t); and the following map update in the bpf program: key = 0; struct tmp_t t = {}; t.a1 = 2; t.a2 = 4; t.a3 = 6; t.b = 7; t.b1 = 8; t.b2 = 10; bpf_map_update_elem(&tmpmap, &key, &t, 0); With this patch, I am able to print out the map values correctly with this patch: bpftool map dump id 187 [{ "key": 0, "value": { "a1": 0x2, "a2": 0x4, "a3": 0x6, "b": 7, "b1": 0x8, "b2": 0xa } } ] Previously, if a function prototype argument has a typedef type, the prototype is not printed since function __btf_dumper_type_only() bailed out with error if the type is a typedef. This commit corrected this behavior by printing out typedef properly. The following example shows forward type and typedef type can be properly printed in function prototype with modified test_btf_haskv.c. struct t; union u; __attribute__((noinline)) static int test_long_fname_1(struct dummy_tracepoint_args *arg, struct t *p1, union u *p2, __u32 unused) ... int _dummy_tracepoint(struct dummy_tracepoint_args *arg) { return test_long_fname_1(arg, 0, 0, 0); } $ bpftool p d xlated id 24 ... int test_long_fname_1(struct dummy_tracepoint_args * arg, struct t * p1, union u * p2, __u32 unused) ... Acked-by: Martin KaFai Lau Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann