1. 29 4月, 2020 2 次提交
  2. 14 3月, 2020 2 次提交
  3. 13 3月, 2020 1 次提交
  4. 05 3月, 2020 1 次提交
  5. 27 2月, 2020 1 次提交
  6. 26 2月, 2020 1 次提交
    • A
      selftests/bpf: Print backtrace on SIGSEGV in test_progs · 9fb156bb
      Andrii Nakryiko 提交于
      Due to various bugs in tests clean up code (usually), if host system is
      misconfigured, it happens that test_progs will just crash in the middle of
      running a test with little to no indication of where and why the crash
      happened. For cases where coredump is not readily available (e.g., inside
      a CI), it's very helpful to have a stack trace, which lead to crash, to be
      printed out. This change adds a signal handler that will capture and print out
      symbolized backtrace:
      
        $ sudo ./test_progs -t mmap
        test_mmap:PASS:skel_open_and_load 0 nsec
        test_mmap:PASS:bss_mmap 0 nsec
        test_mmap:PASS:data_mmap 0 nsec
        Caught signal #11!
        Stack trace:
        ./test_progs(crash_handler+0x18)[0x42a888]
        /lib64/libpthread.so.0(+0xf5d0)[0x7f2aab5175d0]
        ./test_progs(test_mmap+0x3c0)[0x41f0a0]
        ./test_progs(main+0x160)[0x407d10]
        /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f2aab15d3d5]
        ./test_progs[0x407ebc]
        [1]    1988412 segmentation fault (core dumped)  sudo ./test_progs -t mmap
      
      Unfortunately, glibc's symbolization support is unable to symbolize static
      functions, only global ones will be present in stack trace. But it's still a
      step forward without adding extra libraries to get a better symbolization.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20200225000847.3965188-1-andriin@fb.com
      9fb156bb
  7. 20 2月, 2020 1 次提交
  8. 24 1月, 2020 1 次提交
  9. 23 1月, 2020 1 次提交
  10. 21 1月, 2020 3 次提交
  11. 15 1月, 2020 1 次提交
  12. 14 1月, 2020 1 次提交
  13. 10 1月, 2020 3 次提交
  14. 27 12月, 2019 1 次提交
  15. 23 12月, 2019 1 次提交
  16. 20 12月, 2019 1 次提交
    • A
      selftests/bpf: Convert test_cgroup_attach to prog_tests · 257c8855
      Andrey Ignatov 提交于
      Convert test_cgroup_attach to prog_tests.
      
      This change does a lot of things but in many cases it's pretty expensive
      to separate them, so they go in one commit. Nevertheless the logic is
      ketp as is and changes made are just moving things around, simplifying
      them (w/o changing the meaning of the tests) and making prog_tests
      compatible:
      
      * split the 3 tests in the file into 3 separate files in prog_tests/;
      
      * rename the test functions to test_<file_base_name>;
      
      * remove unused includes, constants, variables and functions from every
        test;
      
      * replace `if`-s with or `if (CHECK())` where additional context should
        be logged and with `if (CHECK_FAIL())` where line number is enough;
      
      * switch from `log_err()` to logging via `CHECK()`;
      
      * replace `assert`-s with `CHECK_FAIL()` to avoid crashing the whole
        test_progs if one assertion fails;
      
      * replace cgroup_helpers with test__join_cgroup() in
        cgroup_attach_override only, other tests need more fine-grained
        control for cgroup creation/deletion so cgroup_helpers are still used
        there;
      
      * simplify cgroup_attach_autodetach by switching to easiest possible
        program since this test doesn't really need such a complicated program
        as cgroup_attach_multi does;
      
      * remove test_cgroup_attach.c itself.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/0ff19cc64d2dc5cf404349f07131119480e10e32.1576741281.git.rdna@fb.com
      257c8855
  17. 18 12月, 2019 1 次提交
  18. 16 12月, 2019 2 次提交
    • A
      libbpf: Support libbpf-provided extern variables · 166750bc
      Andrii Nakryiko 提交于
      Add support for extern variables, provided to BPF program by libbpf. Currently
      the following extern variables are supported:
        - LINUX_KERNEL_VERSION; version of a kernel in which BPF program is
          executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte
          long;
        - CONFIG_xxx values; a set of values of actual kernel config. Tristate,
          boolean, strings, and integer values are supported.
      
      Set of possible values is determined by declared type of extern variable.
      Supported types of variables are:
      - Tristate values. Are represented as `enum libbpf_tristate`. Accepted values
        are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO,
        or TRI_MODULE, respectively.
      - Boolean values. Are represented as bool (_Bool) types. Accepted values are
        'y' and 'n' only, turning into true/false values, respectively.
      - Single-character values. Can be used both as a substritute for
        bool/tristate, or as a small-range integer:
        - 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm';
        - integers in a range [-128, 127] or [0, 255] (depending on signedness of
          char in target architecture) are recognized and represented with
          respective values of char type.
      - Strings. String values are declared as fixed-length char arrays. String of
        up to that length will be accepted and put in first N bytes of char array,
        with the rest of bytes zeroed out. If config string value is longer than
        space alloted, it will be truncated and warning message emitted. Char array
        is always zero terminated. String literals in config have to be enclosed in
        double quotes, just like C-style string literals.
      - Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and
        unsigned variants. Libbpf enforces parsed config value to be in the
        supported range of corresponding integer type. Integers values in config can
        be:
        - decimal integers, with optional + and - signs;
        - hexadecimal integers, prefixed with 0x or 0X;
        - octal integers, starting with 0.
      
      Config file itself is searched in /boot/config-$(uname -r) location with
      fallback to /proc/config.gz, unless config path is specified explicitly
      through bpf_object_open_opts' kernel_config_path option. Both gzipped and
      plain text formats are supported. Libbpf adds explicit dependency on zlib
      because of this, but this shouldn't be a problem, given libelf already depends
      on zlib.
      
      All detected extern variables, are put into a separate .extern internal map.
      It, similarly to .rodata map, is marked as read-only from BPF program side, as
      well as is frozen on load. This allows BPF verifier to track extern values as
      constants and perform enhanced branch prediction and dead code elimination.
      This can be relied upon for doing kernel version/feature detection and using
      potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF
      program, while still having a single version of BPF program running on old and
      new kernels. Selftests are validating this explicitly for unexisting BPF
      helper.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com
      166750bc
    • A
      selftests/bpf: Add BPF skeletons selftests and convert attach_probe.c · f3c926a4
      Andrii Nakryiko 提交于
      Add BPF skeleton generation to selftest/bpf's Makefile. Convert attach_probe.c
      to use skeleton.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20191214014341.3442258-15-andriin@fb.com
      f3c926a4
  19. 14 12月, 2019 1 次提交
  20. 05 12月, 2019 1 次提交
  21. 25 11月, 2019 1 次提交
  22. 20 11月, 2019 1 次提交
  23. 19 11月, 2019 1 次提交
  24. 12 11月, 2019 1 次提交
  25. 28 10月, 2019 2 次提交
  26. 24 10月, 2019 2 次提交
  27. 23 10月, 2019 1 次提交
  28. 18 10月, 2019 4 次提交
    • A
      selftest/bpf: Remove test_libbpf.sh and test_libbpf_open · cb79a4e1
      Andrii Nakryiko 提交于
      test_progs is much more sophisticated superset of tests compared to
      test_libbpf.sh and test_libbpf_open. Remove test_libbpf.sh and
      test_libbpf_open.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191016060051.2024182-8-andriin@fb.com
      cb79a4e1
    • A
      selftests/bpf: Move test_queue_stack_map.h into progs/ where it belongs · 5ac93074
      Andrii Nakryiko 提交于
      test_queue_stack_map.h is used only from BPF programs. Thus it should be
      part of progs/ subdir. An added benefit of moving it there is that new
      TEST_RUNNER_DEFINE_RULES macro-rule will properly capture dependency on
      this header for all BPF objects and trigger re-build, if it changes.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191016060051.2024182-7-andriin@fb.com
      5ac93074
    • A
      selftests/bpf: Replace test_progs and test_maps w/ general rule · 74b5a596
      Andrii Nakryiko 提交于
      Define test runner generation meta-rule that codifies dependencies
      between test runner, its tests, and its dependent BPF programs. Use that
      for defining test_progs and test_maps test-runners. Also additionally define
      2 flavors of test_progs:
      - alu32, which builds BPF programs with 32-bit registers codegen;
      - bpf_gcc, which build BPF programs using GCC, if it supports BPF target.
      
      Overall, this is accomplished through $(eval)'ing a set of generic
      rules, which defines Makefile targets dynamically at runtime. See
      comments explaining the need for 2 $(evals), though.
      
      For each test runner we have (test_maps and test_progs, currently), and,
      optionally, their flavors, the logic of build process is modeled as
      follows (using test_progs as an example):
      - all BPF objects are in progs/:
        - BPF object's .o file is built into output directory from
          corresponding progs/.c file;
        - all BPF objects in progs/*.c depend on all progs/*.h headers;
        - all BPF objects depend on bpf_*.h helpers from libbpf (but not
          libbpf archive). There is an extra rule to trigger bpf_helper_defs.h
          (re-)build, if it's not present/outdated);
        - build recipe for BPF object can be re-defined per test runner/flavor;
      - test files are built from prog_tests/*.c:
        - all such test file objects are built on individual file basis;
        - currently, every single test file depends on all BPF object files;
          this might be improved in follow up patches to do 1-to-1 dependency,
          but allowing to customize this per each individual test;
        - each test runner definition can specify a list of extra .c and .h
          files to be built along test files and test runner binary; all such
          headers are becoming automatic dependency of each test .c file;
        - due to test files sometimes embedding (using .incbin assembly
          directive) contents of some BPF objects at compilation time, which are
          expected to be in CWD of compiler, compilation for test file object does
          cd into test runner's output directory; to support this mode all the
          include paths are turned into absolute paths using $(abspath) make
          function;
      - prog_tests/test.h is automatically (re-)generated with an entry for
        each .c file in prog_tests/;
      - final test runner binary is linked together from test object files and
        extra object files, linking together libbpf's archive as well;
      - it's possible to specify extra "resource" files/targets, which will be
        copied into test runner output directory, if it differes from
        Makefile-wide $(OUTPUT). This is used to ensure btf_dump test cases and
        urandom_read binary is put into a test runner's CWD for tests to find
        them in runtime.
      
      For flavored test runners, their output directory is a subdirectory of
      common Makefile-wide $(OUTPUT) directory with flavor name used as
      subdirectory name.
      
      BPF objects targets might be reused between different test runners, so
      extra checks are employed to not double-define them. Similarly, we have
      redefinition guards for output directories and test headers.
      
      test_verifier follows slightly different patterns and is simple enough
      to not justify generalizing TEST_RUNNER_DEFINE/TEST_RUNNER_DEFINE_RULES
      further to accomodate these differences. Instead, rules for
      test_verifier are minimized and simplified, while preserving correctness
      of dependencies.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191016060051.2024182-6-andriin@fb.com
      74b5a596
    • A
      selftests/bpf: Add simple per-test targets to Makefile · 03dcb784
      Andrii Nakryiko 提交于
      Currently it's impossible to do `make test_progs` and have only
      test_progs be built, because all the binary targets are defined in terms
      of $(OUTPUT)/<binary>, and $(OUTPUT) is absolute path to current
      directory (or whatever gets overridden to by user).
      
      This patch adds simple re-directing targets for all test targets making
      it possible to do simple and nice `make test_progs` (and any other
      target).
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191016060051.2024182-5-andriin@fb.com
      03dcb784