1. 12 11月, 2020 3 次提交
  2. 19 9月, 2020 1 次提交
  3. 28 8月, 2020 1 次提交
  4. 26 7月, 2020 1 次提交
  5. 02 7月, 2020 1 次提交
    • A
      tools/bpftool: Turn off -Wnested-externs warning · 17bbf925
      Andrii Nakryiko 提交于
      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: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200701212816.2072340-1-andriin@fb.com
      17bbf925
  6. 01 7月, 2020 1 次提交
  7. 24 6月, 2020 1 次提交
  8. 23 6月, 2020 3 次提交
  9. 03 6月, 2020 1 次提交
  10. 30 4月, 2020 2 次提交
  11. 14 3月, 2020 1 次提交
  12. 13 3月, 2020 2 次提交
  13. 12 3月, 2020 1 次提交
  14. 10 3月, 2020 1 次提交
    • S
      bpftool: Introduce "prog profile" command · 47c09d6a
      Song Liu 提交于
      With fentry/fexit programs, it is possible to profile BPF program with
      hardware counters. Introduce bpftool "prog profile", which measures key
      metrics of a BPF program.
      
      bpftool prog profile command creates per-cpu perf events. Then it attaches
      fentry/fexit programs to the target BPF program. The fentry program saves
      perf event value to a map. The fexit program reads the perf event again,
      and calculates the difference, which is the instructions/cycles used by
      the target program.
      
      Example input and output:
      
        ./bpftool prog profile id 337 duration 3 cycles instructions llc_misses
      
              4228 run_cnt
           3403698 cycles                                              (84.08%)
           3525294 instructions   #  1.04 insn per cycle               (84.05%)
                13 llc_misses     #  3.69 LLC misses per million isns  (83.50%)
      
      This command measures cycles and instructions for BPF program with id
      337 for 3 seconds. The program has triggered 4228 times. The rest of the
      output is similar to perf-stat. In this example, the counters were only
      counting ~84% of the time because of time multiplexing of perf counters.
      
      Note that, this approach measures cycles and instructions in very small
      increments. So the fentry/fexit programs introduce noticeable errors to
      the measurement results.
      
      The fentry/fexit programs are generated with BPF skeletons. Therefore, we
      build bpftool twice. The first time _bpftool is built without skeletons.
      Then, _bpftool is used to generate the skeletons. The second time, bpftool
      is built with skeletons.
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: NQuentin Monnet <quentin@isovalent.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200309173218.2739965-2-songliubraving@fb.com
      47c09d6a
  15. 21 1月, 2020 1 次提交
  16. 31 8月, 2019 4 次提交
    • Q
      tools: bpftool: do not link twice against libbpf.a in Makefile · 5b84ad2e
      Quentin Monnet 提交于
      In bpftool's Makefile, $(LIBS) includes $(LIBBPF), therefore the library
      is used twice in the linking command. No need to have $(LIBBPF) (from
      $^) on that command, let's do with "$(OBJS) $(LIBS)" (but move $(LIBBPF)
      _before_ the -l flags in $(LIBS)).
      Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      5b84ad2e
    • Q
      tools: bpf: account for generated feature/ and libbpf/ directories · fbdb620b
      Quentin Monnet 提交于
      When building "tools/bpf" from the top of the Linux repository, the
      build system passes a value for the $(OUTPUT) Makefile variable to
      tools/bpf/Makefile and tools/bpf/bpftool/Makefile, which results in
      generating "libbpf/" (for bpftool) and "feature/" (bpf and bpftool)
      directories inside the tree.
      
      This commit adds such directories to the relevant .gitignore files, and
      edits the Makefiles to ensure they are removed on "make clean". The use
      of "rm" is also made consistent throughout those Makefiles (relies on
      the $(RM) variable, use "--" to prevent interpreting
      $(OUTPUT)/$(DESTDIR) as options.
      
      v2:
      - New patch.
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      fbdb620b
    • Q
      tools: bpftool: improve and check builds for different make invocations · 45c5589d
      Quentin Monnet 提交于
      There are a number of alternative "make" invocations that can be used to
      compile bpftool. The following invocations are expected to work:
      
        - through the kbuild system, from the top of the repository
          (make tools/bpf)
        - by telling make to change to the bpftool directory
          (make -C tools/bpf/bpftool)
        - by building the BPF tools from tools/
          (cd tools && make bpf)
        - by running make from bpftool directory
          (cd tools/bpf/bpftool && make)
      
      Additionally, setting the O or OUTPUT variables should tell the build
      system to use a custom output path, for each of these alternatives.
      
      The following patch fixes the following invocations:
      
        $ make tools/bpf
        $ make tools/bpf O=<dir>
        $ make -C tools/bpf/bpftool OUTPUT=<dir>
        $ make -C tools/bpf/bpftool O=<dir>
        $ cd tools/ && make bpf O=<dir>
        $ cd tools/bpf/bpftool && make OUTPUT=<dir>
        $ cd tools/bpf/bpftool && make O=<dir>
      
      After this commit, the build still fails for two variants when passing
      the OUTPUT variable:
      
        $ make tools/bpf OUTPUT=<dir>
        $ cd tools/ && make bpf OUTPUT=<dir>
      
      In order to remember and check what make invocations are supposed to
      work, and to document the ones which do not, a new script is added to
      the BPF selftests. Note that some invocations require the kernel to be
      configured, so the script skips them if no .config file is found.
      
      v2:
      - In make_and_clean(), set $ERROR to 1 when "make" returns non-zero,
        even if the binary was produced.
      - Run "make clean" from the correct directory (bpf/ instead of bpftool/,
        when relevant).
      Reported-by: NLorenz Bauer <lmb@cloudflare.com>
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      45c5589d
    • Q
      tools: bpftool: ignore make built-in rules for getting kernel version · e0a43aa3
      Quentin Monnet 提交于
      Bpftool calls the toplevel Makefile to get the kernel version for the
      sources it is built from. But when the utility is built from the top of
      the kernel repository, it may dump the following error message for
      certain architectures (including x86):
      
          $ make tools/bpf
          [...]
          make[3]: *** [checkbin] Error 1
          [...]
      
      This does not prevent bpftool compilation, but may feel disconcerting.
      The "checkbin" arch-dependent target is not supposed to be called for
      target "kernelversion", which is a simple "echo" of the version number.
      
      It turns out this is caused by the make invocation in tools/bpf/bpftool,
      which attempts to find implicit rules to apply. Extract from debug
      output:
      
          Reading makefiles...
          Reading makefile 'Makefile'...
          Reading makefile 'scripts/Kbuild.include' (search path) (no ~ expansion)...
          Reading makefile 'scripts/subarch.include' (search path) (no ~ expansion)...
          Reading makefile 'arch/x86/Makefile' (search path) (no ~ expansion)...
          Reading makefile 'scripts/Makefile.kcov' (search path) (no ~ expansion)...
          Reading makefile 'scripts/Makefile.gcc-plugins' (search path) (no ~ expansion)...
          Reading makefile 'scripts/Makefile.kasan' (search path) (no ~ expansion)...
          Reading makefile 'scripts/Makefile.extrawarn' (search path) (no ~ expansion)...
          Reading makefile 'scripts/Makefile.ubsan' (search path) (no ~ expansion)...
          Updating makefiles....
           Considering target file 'scripts/Makefile.ubsan'.
            Looking for an implicit rule for 'scripts/Makefile.ubsan'.
            Trying pattern rule with stem 'Makefile.ubsan'.
          [...]
            Trying pattern rule with stem 'Makefile.ubsan'.
            Trying implicit prerequisite 'scripts/Makefile.ubsan.o'.
            Looking for a rule with intermediate file 'scripts/Makefile.ubsan.o'.
             Avoiding implicit rule recursion.
             Trying pattern rule with stem 'Makefile.ubsan'.
             Trying rule prerequisite 'prepare'.
             Trying rule prerequisite 'FORCE'.
            Found an implicit rule for 'scripts/Makefile.ubsan'.
              Considering target file 'prepare'.
               File 'prepare' does not exist.
                Considering target file 'prepare0'.
                 File 'prepare0' does not exist.
                  Considering target file 'archprepare'.
                   File 'archprepare' does not exist.
                    Considering target file 'archheaders'.
                     File 'archheaders' does not exist.
                     Finished prerequisites of target file 'archheaders'.
                    Must remake target 'archheaders'.
          Putting child 0x55976f4f6980 (archheaders) PID 31743 on the chain.
      
      To avoid that, pass the -r and -R flags to eliminate the use of make
      built-in rules (and while at it, built-in variables) when running
      command "make kernelversion" from bpftool's Makefile.
      Signed-off-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      e0a43aa3
  17. 15 8月, 2019 1 次提交
  18. 13 8月, 2019 1 次提交
  19. 12 8月, 2019 1 次提交
  20. 21 5月, 2019 1 次提交
  21. 16 1月, 2019 1 次提交
  22. 20 12月, 2018 1 次提交
  23. 17 11月, 2018 1 次提交
    • S
      bpftool: make libbfd optional · 29a9c10e
      Stanislav Fomichev 提交于
      Make it possible to build bpftool without libbfd. libbfd and libopcodes are
      typically provided in dev/dbg packages (binutils-dev in debian) which we
      usually don't have installed on the fleet machines and we'd like a way to have
      bpftool version that works without installing any additional packages.
      This excludes support for disassembling jit-ted code and prints an error if
      the user tries to use these features.
      
      Tested by:
      cat > FEATURES_DUMP.bpftool <<EOF
      feature-libbfd=0
      feature-disassembler-four-args=1
      feature-reallocarray=0
      feature-libelf=1
      feature-libelf-mmap=1
      feature-bpf=1
      EOF
      FEATURES_DUMP=$PWD/FEATURES_DUMP.bpftool make
      ldd bpftool | grep libbfd
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      29a9c10e
  24. 11 10月, 2018 2 次提交
  25. 17 7月, 2018 1 次提交
  26. 12 7月, 2018 1 次提交
  27. 01 7月, 2018 1 次提交
  28. 05 5月, 2018 1 次提交
  29. 16 3月, 2018 2 次提交