1. Jul 02, 2020
    • Jesper Dangaard Brouer's avatar
      selftests/bpf: Test_progs option for getting number of tests · 643e7233
      Jesper Dangaard Brouer authored
      
      
      It can be practial to get the number of tests that test_progs contain.
      This could for example be used to create a shell for-loop construct that
      runs the individual tests.
      
      Like:
       for N in $(seq 1 $(./test_progs -c)); do
         ./test_progs -n $N 2>&1 > result_test_${N}.log &
       done ; wait
      
      V2: Add the ability to return the count for the selected tests. This is
      useful for getting a count e.g. after excluding some tests with option -b.
      The current beakers test script like to report the max test count upfront.
      
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159363985244.930467.12617117873058936829.stgit@firesoul
      643e7233
    • Jesper Dangaard Brouer's avatar
      selftests/bpf: Test_progs indicate to shell on non-actions · 6c92bd5c
      Jesper Dangaard Brouer authored
      
      
      When a user selects a non-existing test the summary is printed with
      indication 0 for all info types, and shell "success" (EXIT_SUCCESS) is
      indicated. This can be understood by a human end-user, but for shell
      scripting is it useful to indicate a shell failure (EXIT_FAILURE).
      
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/159363984736.930467.17956007131403952343.stgit@firesoul
      6c92bd5c
    • Andrii Nakryiko's avatar
      tools/bpftool: Turn off -Wnested-externs warning · 17bbf925
      Andrii Nakryiko authored
      
      
      Turn off -Wnested-externs to avoid annoying warnings in BUILD_BUG_ON macro when
      compiling bpftool:
      
      In file included from /data/users/andriin/linux/tools/include/linux/build_bug.h:5,
                       from /data/users/andriin/linux/tools/include/linux/kernel.h:8,
                       from /data/users/andriin/linux/kernel/bpf/disasm.h:10,
                       from /data/users/andriin/linux/kernel/bpf/disasm.c:8:
      /data/users/andriin/linux/kernel/bpf/disasm.c: In function ‘__func_get_name’:
      /data/users/andriin/linux/tools/include/linux/compiler.h:37:38: warning: nested extern declaration of ‘__compiletime_assert_0’ [-Wnested-externs]
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                            ^~~~~~~~~~~~~~~~~~~~~
      /data/users/andriin/linux/tools/include/linux/compiler.h:16:15: note: in definition of macro ‘__compiletime_assert’
         extern void prefix ## suffix(void) __compiletime_error(msg); \
                     ^~~~~~
      /data/users/andriin/linux/tools/include/linux/compiler.h:37:2: note: in expansion of macro ‘_compiletime_assert’
        _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
        ^~~~~~~~~~~~~~~~~~~
      /data/users/andriin/linux/tools/include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
       #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                           ^~~~~~~~~~~~~~~~~~
      /data/users/andriin/linux/tools/include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
        BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
        ^~~~~~~~~~~~~~~~
      /data/users/andriin/linux/kernel/bpf/disasm.c:20:2: note: in expansion of macro ‘BUILD_BUG_ON’
        BUILD_BUG_ON(ARRAY_SIZE(func_id_str) != __BPF_FUNC_MAX_ID);
        ^~~~~~~~~~~~
      
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200701212816.2072340-1-andriin@fb.com
      17bbf925
    • Hao Luo's avatar
      selftests/bpf: Switch test_vmlinux to use hrtimer_range_start_ns. · 8d821b5d
      Hao Luo authored
      The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing
      programs. But in a kernel built by clang, which performs more aggresive
      inlining, that function gets inlined into its caller SyS_nanosleep.
      Therefore, even though fentry and kprobe do hook on the function,
      they aren't triggered by the call to nanosleep in the test.
      
      A possible fix is switching to use a function that is less likely to
      be inlined, such as hrtimer_range_start_ns. The EXPORT_SYMBOL functions
      shouldn't be inlined based on the description of [1], therefore safe
      to use for this test. Also the arguments of this function include the
      duration of sleep, therefore suitable for test verification.
      
      [1] af3b5628
      
       time: don't inline EXPORT_SYMBOL functions
      
      Tested:
       In a clang build kernel, before this change, the test fails:
      
       test_vmlinux:PASS:skel_open 0 nsec
       test_vmlinux:PASS:skel_attach 0 nsec
       test_vmlinux:PASS:tp 0 nsec
       test_vmlinux:PASS:raw_tp 0 nsec
       test_vmlinux:PASS:tp_btf 0 nsec
       test_vmlinux:FAIL:kprobe not called
       test_vmlinux:FAIL:fentry not called
      
       After switching to hrtimer_range_start_ns, the test passes:
      
       test_vmlinux:PASS:skel_open 0 nsec
       test_vmlinux:PASS:skel_attach 0 nsec
       test_vmlinux:PASS:tp 0 nsec
       test_vmlinux:PASS:raw_tp 0 nsec
       test_vmlinux:PASS:tp_btf 0 nsec
       test_vmlinux:PASS:kprobe 0 nsec
       test_vmlinux:PASS:fentry 0 nsec
      
      Signed-off-by: default avatarHao Luo <haoluo@google.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200701175315.1161242-1-haoluo@google.com
      8d821b5d
  2. Jul 01, 2020
  3. Jun 29, 2020
    • Alexei Starovoitov's avatar
      Merge branch 'libbpf_autoload_knob' · afa12644
      Alexei Starovoitov authored
      
      
      Andrii Nakryiko says:
      
      ====================
      Add ability to turn off default auto-loading of each BPF program by libbpf on
      BPF object load. This is the feature that allows BPF applications to have
      optional functionality, which is only excercised on kernel that support
      necessary features, while falling back to reduced/less performant
      functionality, if kernel is outdated.
      ====================
      
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      afa12644
    • Andrii Nakryiko's avatar
      selftests/bpf: Test auto-load disabling logic for BPF programs · 5712174c
      Andrii Nakryiko authored
      
      
      Validate that BPF object with broken (in multiple ways) BPF program can still
      be successfully loaded, if that broken BPF program is disabled.
      
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200625232629.3444003-3-andriin@fb.com
      5712174c
    • Andrii Nakryiko's avatar
      libbpf: Support disabling auto-loading BPF programs · d9297581
      Andrii Nakryiko authored
      
      
      Currently, bpf_object__load() (and by induction skeleton's load), will always
      attempt to prepare, relocate, and load into kernel every single BPF program
      found inside the BPF object file. This is often convenient and the right thing
      to do and what users expect.
      
      But there are plenty of cases (especially with BPF development constantly
      picking up the pace), where BPF application is intended to work with old
      kernels, with potentially reduced set of features. But on kernels supporting
      extra features, it would like to take a full advantage of them, by employing
      extra BPF program. This could be a choice of using fentry/fexit over
      kprobe/kretprobe, if kernel is recent enough and is built with BTF. Or BPF
      program might be providing optimized bpf_iter-based solution that user-space
      might want to use, whenever available. And so on.
      
      With libbpf and BPF CO-RE in particular, it's advantageous to not have to
      maintain two separate BPF object files to achieve this. So to enable such use
      cases, this patch adds ability to request not auto-loading chosen BPF
      programs. In such case, libbpf won't attempt to perform relocations (which
      might fail due to old kernel), won't try to resolve BTF types for
      BTF-aware (tp_btf/fentry/fexit/etc) program types, because BTF might not be
      present, and so on. Skeleton will also automatically skip auto-attachment step
      for such not loaded BPF programs.
      
      Overall, this feature allows to simplify development and deployment of
      real-world BPF applications with complicated compatibility requirements.
      
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200625232629.3444003-2-andriin@fb.com
      d9297581
  4. Jun 25, 2020