kernel.git/tools/testing/selftests/bpf, branch linux-5.8.y

selftests/bpf: Fix test_sysctl_loop{1, 2} failure due to clang change

2020-10-29T09:08:26Z

[ Upstream commit 7fb5eefd76394cfefb380724a87ca40b47d44405 ] Andrii reported that with latest clang, when building selftests, we have error likes: error: progs/test_sysctl_loop1.c:23:16: in function sysctl_tcp_mem i32 (%struct.bpf_sysctl*): Looks like the BPF stack limit of 512 bytes is exceeded. Please move large on stack variables into BPF per-cpu array map. The error is triggered by the following LLVM patch: https://reviews.llvm.org/D87134 For example, the following code is from test_sysctl_loop1.c: static __always_inline int is_tcp_mem(struct bpf_sysctl *ctx) { volatile char tcp_mem_name[] = "net/ipv4/tcp_mem/very_very_very_very_long_pointless_string"; ... } Without the above LLVM patch, the compiler did optimization to load the string (59 bytes long) with 7 64bit loads, 1 8bit load and 1 16bit load, occupying 64 byte stack size. With the above LLVM patch, the compiler only uses 8bit loads, but subregister is 32bit. So stack requirements become 4 * 59 = 236 bytes. Together with other stuff on the stack, total stack size exceeds 512 bytes, hence compiler complains and quits. To fix the issue, removing "volatile" key word or changing "volatile" to "const"/"static const" does not work, the string is put in .rodata.str1.1 section, which libbpf did not process it and errors out with libbpf: elf: skipping unrecognized data section(6) .rodata.str1.1 libbpf: prog 'sysctl_tcp_mem': bad map relo against '.L__const.is_tcp_mem.tcp_mem_name' in section '.rodata.str1.1' Defining the string const as global variable can fix the issue as it puts the string constant in '.rodata' section which is recognized by libbpf. In the future, when libbpf can process '.rodata.str*.*' properly, the global definition can be changed back to local definition. Defining tcp_mem_name as a global, however, triggered a verifier failure. ./test_progs -n 7/21 libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: invalid stack off=0 size=1 verification time 6975 usec stack depth 160+64 processed 889 insns (limit 1000000) max_states_per_insn 4 total_states 14 peak_states 14 mark_read 10 libbpf: -- END LOG -- libbpf: failed to load program 'sysctl_tcp_mem' libbpf: failed to load object 'test_sysctl_loop2.o' test_bpf_verif_scale:FAIL:114 #7/21 test_sysctl_loop2.o:FAIL This actually exposed a bpf program bug. In test_sysctl_loop{1,2}, we have code like const char tcp_mem_name[] = "<...long string...>"; ... char name[64]; ... for (i = 0; i < sizeof(tcp_mem_name); ++i) if (name[i] != tcp_mem_name[i]) return 0; In the above code, if sizeof(tcp_mem_name) > 64, name[i] access may be out of bound. The sizeof(tcp_mem_name) is 59 for test_sysctl_loop1.c and 79 for test_sysctl_loop2.c. Without promotion-to-global change, old compiler generates code where the overflowed stack access is actually filled with valid value, so hiding the bpf program bug. With promotion-to-global change, the code is different, more specifically, the previous loading constants to stack is gone, and "name" occupies stack[-64:0] and overflow access triggers a verifier error. To fix the issue, adjust "name" buffer size properly. Reported-by: Andrii Nakryiko Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200909171542.3673449-1-yhs@fb.com Signed-off-by: Sasha Levin

selftests: Remove fmod_ret from test_overhead

2020-10-29T09:07:46Z

[ Upstream commit b000def2e052fc8ddea31a18019f6ebe044defb3 ] The test_overhead prog_test included an fmod_ret program that attached to __set_task_comm() in the kernel. However, this function was never listed as allowed for return modification, so this only worked because of the verifier skipping tests when a trampoline already existed for the attach point. Now that the verifier checks have been fixed, remove fmod_ret from the test so it works again. Fixes: 4eaf0b5c5e04 ("selftest/bpf: Fmod_ret prog and implement test_overhead as part of bench") Acked-by: Andrii Nakryiko Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

selftests/bpf: Fix endianness issue in test_sockopt_sk

2020-10-29T09:07:40Z

[ Upstream commit fec47bbc10b243690f5d0ee484a0bbdee273e71b ] getsetsockopt() calls getsockopt() with optlen == 1, but then checks the resulting int. It is ok on little endian, but not on big endian. Fix by checking char instead. Fixes: 8a027dc0d8f5 ("selftests/bpf: add sockopt test that exercises sk helpers") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200915113928.3768496-1-iii@linux.ibm.com Signed-off-by: Sasha Levin

selftests/bpf: Fix endianness issue in sk_assign

2020-10-29T09:07:40Z

[ Upstream commit b6ed6cf4a3acdeab9aed8e0a524850761ec9b152 ] server_map's value size is 8, but the test tries to put an int there. This sort of works on x86 (unless followed by non-0), but hard fails on s390. Fix by using __s64 instead of int. Fixes: 2d7824ffd25c ("selftests: bpf: Add test for sk_assign") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200915113815.3768217-1-iii@linux.ibm.com Signed-off-by: Sasha Levin

selftests/bpf: Fix test_vmlinux test to use bpf_probe_read_user()

2020-10-29T09:07:30Z

[ Upstream commit 02f47faa25db134f6043fb6b12a68b5d4c980bb6 ] The test is reading UAPI kernel structure from user-space. So it doesn't need CO-RE relocations and has to use bpf_probe_read_user(). Fixes: acbd06206bbb ("selftests/bpf: Add vmlinux.h selftest exercising tracing of syscalls") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200818213356.2629020-6-andriin@fb.com Signed-off-by: Sasha Levin

selftests/bpf: Fix massive output from test_maps

2020-09-09T17:14:18Z

[ Upstream commit fa4505675e093e895b7ec49a76d44f6b5ad9602e ] When stdout output from the selftests tool 'test_maps' gets redirected into e.g file or pipe, then the output lines increase a lot (from 21 to 33949 lines). This is caused by the printf that happens before the fork() call, and there are user-space buffered printf data that seems to be duplicated into the forked process. To fix this fflush() stdout before the fork loop in __run_parallel(). Fixes: 1a97cf1fe503 ("selftests/bpf: speedup test_maps") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/159842985651.1050885.2154399297503372406.stgit@firesoul Signed-off-by: Sasha Levin

bpf: selftests: global_funcs: Check err_str before strstr

2020-09-03T09:29:38Z

[ Upstream commit c210773d6c6f595f5922d56b7391fe343bc7310e ] The error path in libbpf.c:load_program() has calls to pr_warn() which ends up for global_funcs tests to test_global_funcs.c:libbpf_debug_print(). For the tests with no struct test_def::err_str initialized with a string, it causes call of strstr() with NULL as the second argument and it segfaults. Fix it by calling strstr() only for non-NULL err_str. Signed-off-by: Yauheni Kaliuta Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200820115843.39454-1-yauheni.kaliuta@redhat.com Signed-off-by: Sasha Levin

selftests/bpf: Correct various core_reloc 64-bit assumptions

2020-09-03T09:29:33Z

[ Upstream commit 5705d705832f74395c5465ce93192688f543006a ] Ensure that types are memory layout- and field alignment-compatible regardless of 32/64-bitness mix of libbpf and BPF architecture. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200813204945.1020225-8-andriin@fb.com Signed-off-by: Sasha Levin

selftests/bpf: Fix btf_dump test cases on 32-bit arches

2020-09-03T09:29:33Z

[ Upstream commit eed7818adf03e874994b966aa33bc00204dd275a ] Fix btf_dump test cases by hard-coding BPF's pointer size of 8 bytes for cases where it's impossible to deterimne the pointer size (no long type in BTF). In cases where it's known, validate libbpf correctly determines it as 8. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200813204945.1020225-6-andriin@fb.com Signed-off-by: Sasha Levin

selftest/bpf: Fix compilation warnings in 32-bit mode

2020-09-03T09:29:33Z

[ Upstream commit 9028bbcc3e12510cac13a9554f1a1e39667a4387 ] Fix compilation warnings emitted when compiling selftests for 32-bit platform (x86 in my case). Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200813204945.1020225-3-andriin@fb.com Signed-off-by: Sasha Levin