mirror of
https://github.com/torvalds/linux.git
synced 2024-11-11 06:31:49 +00:00
e00c7b216f
1) The test_lru_map and test_lru_dist fails building on my machine since
the sys/resource.h header is not included.
2) test_verifier fails in one test case where we try to call an invalid
function, since the verifier log output changed wrt printing function
names.
3) Current selftest suite code relies on sysconf(_SC_NPROCESSORS_CONF) for
retrieving the number of possible CPUs. This is broken at least in our
scenario and really just doesn't work.
glibc tries a number of things for retrieving _SC_NPROCESSORS_CONF.
First it tries equivalent of /sys/devices/system/cpu/cpu[0-9]* | wc -l,
if that fails, depending on the config, it either tries to count CPUs
in /proc/cpuinfo, or returns the _SC_NPROCESSORS_ONLN value instead.
If /proc/cpuinfo has some issue, it returns just 1 worst case. This
oddity is nothing new [1], but semantics/behaviour seems to be settled.
_SC_NPROCESSORS_ONLN will parse /sys/devices/system/cpu/online, if
that fails it looks into /proc/stat for cpuX entries, and if also that
fails for some reason, /proc/cpuinfo is consulted (and returning 1 if
unlikely all breaks down).
While that might match num_possible_cpus() from the kernel in some
cases, it's really not guaranteed with CPU hotplugging, and can result
in a buffer overflow since the array in user space could have too few
number of slots, and on perpcu map lookup, the kernel will write beyond
that memory of the value buffer.
William Tu reported such mismatches:
[...] The fact that sysconf(_SC_NPROCESSORS_CONF) != num_possible_cpu()
happens when CPU hotadd is enabled. For example, in Fusion when
setting vcpu.hotadd = "TRUE" or in KVM, setting ./qemu-system-x86_64
-smp 2, maxcpus=4 ... the num_possible_cpu() will be 4 and sysconf()
will be 2 [2]. [...]
Documentation/cputopology.txt says /sys/devices/system/cpu/possible
outputs cpu_possible_mask. That is the same as in num_possible_cpus(),
so first step would be to fix the _SC_NPROCESSORS_CONF calls with our
own implementation. Later, we could add support to bpf(2) for passing
a mask via CPU_SET(3), for example, to just select a subset of CPUs.
BPF samples code needs this fix as well (at least so that people stop
copying this). Thus, define bpf_num_possible_cpus() once in selftests
and import it from there for the sample code to avoid duplicating it.
The remaining sysconf(_SC_NPROCESSORS_CONF) in samples are unrelated.
After all three issues are fixed, the test suite runs fine again:
# make run_tests | grep self
selftests: test_verifier [PASS]
selftests: test_maps [PASS]
selftests: test_lru_map [PASS]
selftests: test_kmod.sh [PASS]
[1] https://www.sourceware.org/ml/libc-alpha/2011-06/msg00079.html
[2] https://www.mail-archive.com/netdev@vger.kernel.org/msg121183.html
Fixes:
|
||
|---|---|---|
| .. | ||
| bpf_helpers.h | ||
| bpf_load.c | ||
| bpf_load.h | ||
| fds_example.c | ||
| lathist_kern.c | ||
| lathist_user.c | ||
| libbpf.c | ||
| libbpf.h | ||
| Makefile | ||
| map_perf_test_kern.c | ||
| map_perf_test_user.c | ||
| offwaketime_kern.c | ||
| offwaketime_user.c | ||
| parse_ldabs.c | ||
| parse_simple.c | ||
| parse_varlen.c | ||
| README.rst | ||
| sampleip_kern.c | ||
| sampleip_user.c | ||
| sock_example.c | ||
| sockex1_kern.c | ||
| sockex1_user.c | ||
| sockex2_kern.c | ||
| sockex2_user.c | ||
| sockex3_kern.c | ||
| sockex3_user.c | ||
| spintest_kern.c | ||
| spintest_user.c | ||
| tc_l2_redirect_kern.c | ||
| tc_l2_redirect_user.c | ||
| tc_l2_redirect.sh | ||
| tcbpf1_kern.c | ||
| tcbpf2_kern.c | ||
| test_cgrp2_array_pin.c | ||
| test_cgrp2_attach.c | ||
| test_cgrp2_tc_kern.c | ||
| test_cgrp2_tc.sh | ||
| test_cls_bpf.sh | ||
| test_current_task_under_cgroup_kern.c | ||
| test_current_task_under_cgroup_user.c | ||
| test_ipip.sh | ||
| test_lru_dist.c | ||
| test_overhead_kprobe_kern.c | ||
| test_overhead_tp_kern.c | ||
| test_overhead_user.c | ||
| test_probe_write_user_kern.c | ||
| test_probe_write_user_user.c | ||
| test_tunnel_bpf.sh | ||
| trace_event_kern.c | ||
| trace_event_user.c | ||
| trace_output_kern.c | ||
| trace_output_user.c | ||
| tracex1_kern.c | ||
| tracex1_user.c | ||
| tracex2_kern.c | ||
| tracex2_user.c | ||
| tracex3_kern.c | ||
| tracex3_user.c | ||
| tracex4_kern.c | ||
| tracex4_user.c | ||
| tracex5_kern.c | ||
| tracex5_user.c | ||
| tracex6_kern.c | ||
| tracex6_user.c | ||
| xdp1_kern.c | ||
| xdp1_user.c | ||
| xdp2_kern.c | ||
eBPF sample programs ==================== This directory contains a mini eBPF library, test stubs, verifier test-suite and examples for using eBPF. Build dependencies ================== Compiling requires having installed: * clang >= version 3.4.0 * llvm >= version 3.7.1 Note that LLVM's tool 'llc' must support target 'bpf', list version and supported targets with command: ``llc --version`` Kernel headers -------------- There are usually dependencies to header files of the current kernel. To avoid installing devel kernel headers system wide, as a normal user, simply call:: make headers_install This will creates a local "usr/include" directory in the git/build top level directory, that the make system automatically pickup first. Compiling ========= For building the BPF samples, issue the below command from the kernel top level directory:: make samples/bpf/ Do notice the "/" slash after the directory name. It is also possible to call make from this directory. This will just hide the the invocation of make as above with the appended "/". Manually compiling LLVM with 'bpf' support ------------------------------------------ Since version 3.7.0, LLVM adds a proper LLVM backend target for the BPF bytecode architecture. By default llvm will build all non-experimental backends including bpf. To generate a smaller llc binary one can use:: -DLLVM_TARGETS_TO_BUILD="BPF" Quick sniplet for manually compiling LLVM and clang (build dependencies are cmake and gcc-c++):: $ git clone http://llvm.org/git/llvm.git $ cd llvm/tools $ git clone --depth 1 http://llvm.org/git/clang.git $ cd ..; mkdir build; cd build $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86" $ make -j $(getconf _NPROCESSORS_ONLN) It is also possible to point make to the newly compiled 'llc' or 'clang' command via redefining LLC or CLANG on the make command line:: make samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang