1. 25 5月, 2019 1 次提交
  2. 17 5月, 2019 1 次提交
  3. 16 4月, 2019 1 次提交
  4. 10 4月, 2019 1 次提交
  5. 27 3月, 2019 1 次提交
    • A
      libbpf: fix btf_dedup equivalence check handling of different kinds · 9ec71c1c
      Andrii Nakryiko 提交于
      btf_dedup_is_equiv() used to compare btf_type->info fields, before doing
      kind-specific equivalence check. This comparsion implicitly verified
      that candidate and canonical types are of the same kind. With enum fwd
      resolution logic this check couldn't be done generically anymore, as for
      enums info contains vlen, which differs between enum fwd and
      fully-defined enum, so this check was subsumed by kind-specific
      equivalence checks.
      
      This change caused btf_dedup_is_equiv() to let through VOID vs other
      types check to reach switch, which was never meant to be handing VOID
      kind, as VOID kind is always pre-resolved to itself and is only
      equivalent to itself, which is checked early in btf_dedup_is_equiv().
      
      This change adds back BTF kind equality check in place of more generic
      btf_type->info check, still defering further kind-specific checks to
      a per-kind switch.
      
      Fixes: 9768095b ("btf: resolve enum fwds in btf_dedup")
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      9ec71c1c
  6. 15 3月, 2019 1 次提交
    • A
      btf: resolve enum fwds in btf_dedup · 9768095b
      Andrii Nakryiko 提交于
      GCC and clang support enum forward declarations as an extension. Such
      forward-declared enums will be represented as normal BTF_KIND_ENUM types with
      vlen=0. This patch adds ability to resolve such enums to their corresponding
      fully defined enums. This helps to avoid duplicated BTF type graphs which only
      differ by some types referencing forward-declared enum vs full enum.
      
      One such example in kernel is enum irqchip_irq_state, defined in
      include/linux/interrupt.h and forward-declared in include/linux/irq.h. This
      causes entire struct task_struct and all referenced types to be duplicated in
      btf_dedup output. This patch eliminates such duplication cases.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      9768095b
  7. 01 3月, 2019 3 次提交
  8. 17 2月, 2019 1 次提交
    • A
      tools/libbpf: support bigger BTF data sizes · 5aab392c
      Andrii Nakryiko 提交于
      While it's understandable why kernel limits number of BTF types to 65535
      and size of string section to 64KB, in libbpf as user-space library it's
      too restrictive. E.g., pahole converting DWARF to BTF type information
      for Linux kernel generates more than 3 million BTF types and more than
      3MB of strings, before deduplication. So to allow btf__dedup() to do its
      work, we need to be able to load bigger BTF sections using btf__new().
      Singed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      5aab392c
  9. 15 2月, 2019 1 次提交
  10. 09 2月, 2019 4 次提交
  11. 08 2月, 2019 1 次提交
  12. 06 2月, 2019 2 次提交
    • Y
      tools/bpf: silence a libbpf unnecessary warning · f7748e29
      Yonghong Song 提交于
      Commit 96408c43 ("tools/bpf: implement libbpf
      btf__get_map_kv_tids() API function") refactored
      function bpf_map_find_btf_info() and moved bulk of
      implementation into btf.c as btf__get_map_kv_tids().
      This change introduced a bug such that test_btf will
      print out the following warning although the test passed:
        BTF libbpf test[2] (test_btf_nokv.o): libbpf: map:btf_map
            container_name:____btf_map_btf_map cannot be found
            in BTF. Missing BPF_ANNOTATE_KV_PAIR?
      
      Previously, the error message is guarded with pr_debug().
      Commit 96408c43 changed it to pr_warning() and
      hence caused the warning.
      
      Restoring to pr_debug() for the message fixed the issue.
      
      Fixes: 96408c43 ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      f7748e29
    • Y
      tools/bpf: add const qualifier to btf__get_map_kv_tids() map_name parameter · a6c109a6
      Yonghong Song 提交于
      Commit 96408c43 ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
      added the API function btf__get_map_kv_tids():
        btf__get_map_kv_tids(const struct btf *btf, char *map_name, ...)
      
      The parameter map_name has type "char *". This is okay inside libbpf library since
      the map_name is from bpf_map->name which also has type "char *".
      
      This will be problematic if the caller for map_name already has attribute "const",
      e.g., from C++ string.c_str(). It will result in either a warning or an error.
      
        /home/yhs/work/bcc/src/cc/btf.cc:166:51:
          error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
            return btf__get_map_kv_tids(btf_, map_name.c_str()
      
      This patch added "const" attributes to map_name parameter.
      
      Fixes: 96408c43 ("tools/bpf: implement libbpf btf__get_map_kv_tids() API function")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      a6c109a6
  13. 05 2月, 2019 6 次提交
    • A
      selftests/btf: add initial BTF dedup tests · 9c651127
      Andrii Nakryiko 提交于
      This patch sets up a new kind of tests (BTF dedup tests) and tests few aspects of
      BTF dedup algorithm. More complete set of tests will come in follow up patches.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      9c651127
    • A
      btf: add BTF types deduplication algorithm · d5caef5b
      Andrii Nakryiko 提交于
      This patch implements BTF types deduplication algorithm. It allows to
      greatly compress typical output of pahole's DWARF-to-BTF conversion or
      LLVM's compilation output by detecting and collapsing identical types emitted in
      isolation per compilation unit. Algorithm also resolves struct/union forward
      declarations into concrete BTF types representing referenced struct/union. If
      undesired, this resolution can be disabled through specifying corresponding options.
      
      Algorithm itself and its application to Linux kernel's BTF types is
      described in details at:
      https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.htmlSigned-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d5caef5b
    • A
      btf: extract BTF type size calculation · 69eaab04
      Andrii Nakryiko 提交于
      This pre-patch extracts calculation of amount of space taken by BTF type descriptor
      for later reuse by btf_dedup functionality.
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      69eaab04
    • Y
      tools/bpf: implement libbpf btf__get_map_kv_tids() API function · 96408c43
      Yonghong Song 提交于
      Currently, to get map key/value type id's, the macro
        BPF_ANNOTATE_KV_PAIR(<map_name>, <key_type>, <value_type>)
      needs to be defined in the bpf program for the
      corresponding map.
      
      During program/map loading time,
      the local static function bpf_map_find_btf_info()
      in libbpf.c is implemented to retrieve the key/value
      type ids given the map name.
      
      The patch refactored function bpf_map_find_btf_info()
      to create an API btf__get_map_kv_tids() which includes
      the bulk of implementation for the original function.
      The API btf__get_map_kv_tids() can be used by bcc,
      a JIT based bpf compilation system, which uses the
      same BPF_ANNOTATE_KV_PAIR to record map key/value types.
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      96408c43
    • Y
      tools/bpf: print out btf log at LIBBPF_WARN level · 9d100a19
      Yonghong Song 提交于
      Currently, the btf log is allocated and printed out in case
      of error at LIBBPF_DEBUG level.
      Such logs from kernel are very important for debugging.
      For example, bpf syscall BPF_PROG_LOAD command can get
      verifier logs back to user space. In function load_program()
      of libbpf.c, the log buffer is allocated unconditionally
      and printed out at pr_warning() level.
      
      Let us do the similar thing here for btf. Allocate buffer
      unconditionally and print out error logs at pr_warning() level.
      This can reduce one global function and
      optimize for common situations where pr_warning()
      is activated either by default or by user supplied
      debug output function.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      9d100a19
    • Y
      tools/bpf: move libbpf pr_* debug print functions to headers · 8461ef8b
      Yonghong Song 提交于
      A global function libbpf_print, which is invisible
      outside the shared library, is defined to print based
      on levels. The pr_warning, pr_info and pr_debug
      macros are moved into the newly created header
      common.h. So any .c file including common.h can
      use these macros directly.
      
      Currently btf__new and btf_ext__new API has an argument getting
      __pr_debug function pointer into btf.c so the debugging information
      can be printed there. This patch removed this parameter
      from btf__new and btf_ext__new and directly using pr_debug in btf.c.
      
      Another global function libbpf_print_level_available, also
      invisible outside the shared library, can test
      whether a particular level debug printing is
      available or not. It is used in btf.c to
      test whether DEBUG level debug printing is availabl or not,
      based on which the log buffer will be allocated when loading
      btf to the kernel.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      8461ef8b
  14. 10 12月, 2018 2 次提交
    • M
      bpf: libbpf: Add btf_line_info support to libbpf · 3d650141
      Martin KaFai Lau 提交于
      This patch adds bpf_line_info support to libbpf:
      1) Parsing the line_info sec from ".BTF.ext"
      2) Relocating the line_info.  If the main prog *_info relocation
         fails, it will ignore the remaining subprog line_info and continue.
         If the subprog *_info relocation fails, it will bail out.
      3) BPF_PROG_LOAD a prog with line_info
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      3d650141
    • M
      bpf: libbpf: Refactor and bug fix on the bpf_func_info loading logic · f0187f0b
      Martin KaFai Lau 提交于
      This patch refactor and fix a bug in the libbpf's bpf_func_info loading
      logic.  The bug fix and refactoring are targeting the same
      commit 2993e051 ("tools/bpf: add support to read .BTF.ext sections")
      which is in the bpf-next branch.
      
      1) In bpf_load_program_xattr(), it should retry when errno == E2BIG
         regardless of log_buf and log_buf_sz.  This patch fixes it.
      
      2) btf_ext__reloc_init() and btf_ext__reloc() are essentially
         the same except btf_ext__reloc_init() always has insns_cnt == 0.
         Hence, btf_ext__reloc_init() is removed.
      
         btf_ext__reloc() is also renamed to btf_ext__reloc_func_info()
         to get ready for the line_info support in the next patch.
      
      3) Consolidate func_info section logic from "btf_ext_parse_hdr()",
         "btf_ext_validate_func_info()" and "btf_ext__new()" to
         a new function "btf_ext_copy_func_info()" such that similar
         logic can be reused by the later libbpf's line_info patch.
      
      4) The next line_info patch will store line_info_cnt instead of
         line_info_len in the bpf_program because the kernel is taking
         line_info_cnt also.  It will save a few "len" to "cnt" conversions
         and will also save some function args.
      
         Hence, this patch also makes bpf_program to store func_info_cnt
         instead of func_info_len.
      
      5) btf_ext depends on btf.  e.g. the func_info's type_id
         in ".BTF.ext" is not useful when ".BTF" is absent.
         This patch only init the obj->btf_ext pointer after
         it has successfully init the obj->btf pointer.
      
         This can avoid always checking "obj->btf && obj->btf_ext"
         together for accessing ".BTF.ext".  Checking "obj->btf_ext"
         alone will do.
      
      6) Move "struct btf_sec_func_info" from btf.h to btf.c.
         There is no external usage outside btf.c.
      
      Fixes: 2993e051 ("tools/bpf: add support to read .BTF.ext sections")
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      f0187f0b
  15. 06 12月, 2018 1 次提交
  16. 29 11月, 2018 1 次提交
  17. 27 11月, 2018 1 次提交
  18. 21 11月, 2018 3 次提交
  19. 08 10月, 2018 1 次提交
  20. 06 8月, 2018 1 次提交
  21. 03 8月, 2018 1 次提交
  22. 25 7月, 2018 2 次提交
  23. 14 7月, 2018 1 次提交
  24. 23 5月, 2018 1 次提交
  25. 23 4月, 2018 1 次提交