1. 29 3月, 2019 1 次提交
  2. 25 3月, 2019 2 次提交
    • D
      bpf, libbpf: clarify bump in libbpf version info · 63197f78
      Daniel Borkmann 提交于
      The current documentation suggests that we would need to bump the
      libbpf version on every change. Lets clarify this a bit more and
      reflect what we do today in practice, that is, bumping it once per
      development cycle.
      
      Fixes: 76d1b894 ("libbpf: Document API and ABI conventions")
      Reported-by: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      63197f78
    • D
      bpf, libbpf: fix version info and add it to shared object · 1d382264
      Daniel Borkmann 提交于
      Even though libbpf's versioning script for the linker (libbpf.map)
      is pointing to 0.0.2, the BPF_EXTRAVERSION in the Makefile has
      not been updated along with it and is therefore still on 0.0.1.
      
      While fixing up, I also noticed that the generated shared object
      versioning information is missing, typical convention is to have
      a linker name (libbpf.so), soname (libbpf.so.0) and real name
      (libbpf.so.0.0.2) for library management. This is based upon the
      LIBBPF_VERSION as well.
      
      The build will then produce the following bpf libraries:
      
        # ll libbpf*
        libbpf.a
        libbpf.so -> libbpf.so.0.0.2
        libbpf.so.0 -> libbpf.so.0.0.2
        libbpf.so.0.0.2
      
        # readelf -d libbpf.so.0.0.2 | grep SONAME
        0x000000000000000e (SONAME)             Library soname: [libbpf.so.0]
      
      And install them accordingly:
      
        # rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld install
      
        Auto-detecting system features:
        ...                        libelf: [ on  ]
        ...                           bpf: [ on  ]
      
          CC       /tmp/bld/libbpf.o
          CC       /tmp/bld/bpf.o
          CC       /tmp/bld/nlattr.o
          CC       /tmp/bld/btf.o
          CC       /tmp/bld/libbpf_errno.o
          CC       /tmp/bld/str_error.o
          CC       /tmp/bld/netlink.o
          CC       /tmp/bld/bpf_prog_linfo.o
          CC       /tmp/bld/libbpf_probes.o
          CC       /tmp/bld/xsk.o
          LD       /tmp/bld/libbpf-in.o
          LINK     /tmp/bld/libbpf.a
          LINK     /tmp/bld/libbpf.so.0.0.2
          LINK     /tmp/bld/test_libbpf
          INSTALL  /tmp/bld/libbpf.a
          INSTALL  /tmp/bld/libbpf.so.0.0.2
      
        # ll /usr/local/lib64/libbpf.*
        /usr/local/lib64/libbpf.a
        /usr/local/lib64/libbpf.so -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0 -> libbpf.so.0.0.2
        /usr/local/lib64/libbpf.so.0.0.2
      
      Fixes: 1bf4b058 ("tools: bpftool: add probes for eBPF program types")
      Fixes: 1b76c13e ("bpf tools: Introduce 'bpf' library and add bpf feature check")
      Reported-by: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      1d382264
  3. 20 3月, 2019 2 次提交
  4. 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
  5. 13 3月, 2019 1 次提交
  6. 12 3月, 2019 1 次提交
    • A
      tools lib bpf: Fix the build by adding a missing stdarg.h include · dfcbc2f2
      Arnaldo Carvalho de Melo 提交于
      The libbpf_print_fn_t typedef uses va_list without including the header
      where that type is defined, stdarg.h, breaking in places where we're
      unlucky for that type not to be already defined by some previously
      included header.
      
      Noticed while building on fedora 24 cross building tools/perf to the ARC
      architecture using the uClibc C library:
      
        28 fedora:24-x-ARC-uClibc   : FAIL arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
      
          CC       /tmp/build/perf/tests/llvm.o
        In file included from tests/llvm.c:3:0:
        /git/linux/tools/lib/bpf/libbpf.h:57:20: error: unknown type name 'va_list'
              const char *, va_list ap);
                            ^~~~~~~
        /git/linux/tools/lib/bpf/libbpf.h:59:34: error: unknown type name 'libbpf_print_fn_t'
         LIBBPF_API void libbpf_set_print(libbpf_print_fn_t fn);
                                          ^~~~~~~~~~~~~~~~~
        mv: cannot stat '/tmp/build/perf/tests/.llvm.o.tmp': No such file or directory
      
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Quentin Monnet <quentin.monnet@netronome.com>
      Cc: Stanislav Fomichev <sdf@google.com>
      Cc: Yonghong Song <yhs@fb.com>
      Fixes: a8a1f7d0 ("libbpf: fix libbpf_print")
      Link: https://lkml.kernel.org/n/tip-5270n2quu2gqz22o7itfdx00@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dfcbc2f2
  7. 11 3月, 2019 1 次提交
  8. 09 3月, 2019 1 次提交
  9. 07 3月, 2019 1 次提交
    • S
      libbpf: force fixdep compilation at the start of the build · 8e268887
      Stanislav Fomichev 提交于
      libbpf targets don't explicitly depend on fixdep target, so when
      we do 'make -j$(nproc)', there is a high probability, that some
      objects will be built before fixdep binary is available.
      
      Fix this by running sub-make; this makes sure that fixdep dependency
      is properly accounted for.
      
      For the same issue in perf, see commit abb26210 ("perf tools: Force
      fixdep compilation at the start of the build").
      
      Before:
      
      $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/
      
      Auto-detecting system features:
      ...                        libelf: [ on  ]
      ...                           bpf: [ on  ]
      
        HOSTCC   /tmp/bld/fixdep.o
        CC       /tmp/bld/libbpf.o
        CC       /tmp/bld/bpf.o
        CC       /tmp/bld/btf.o
        CC       /tmp/bld/nlattr.o
        CC       /tmp/bld/libbpf_errno.o
        CC       /tmp/bld/str_error.o
        CC       /tmp/bld/netlink.o
        CC       /tmp/bld/bpf_prog_linfo.o
        CC       /tmp/bld/libbpf_probes.o
        CC       /tmp/bld/xsk.o
        HOSTLD   /tmp/bld/fixdep-in.o
        LINK     /tmp/bld/fixdep
        LD       /tmp/bld/libbpf-in.o
        LINK     /tmp/bld/libbpf.a
        LINK     /tmp/bld/libbpf.so
        LINK     /tmp/bld/test_libbpf
      
      $ head /tmp/bld/.libbpf.o.cmd
       # cannot find fixdep (/usr/local/google/home/sdf/src/linux/xxx//fixdep)
       # using basic dep data
      
      /tmp/bld/libbpf.o: libbpf.c /usr/include/stdc-predef.h \
       /usr/include/stdlib.h /usr/include/features.h \
       /usr/include/x86_64-linux-gnu/sys/cdefs.h \
       /usr/include/x86_64-linux-gnu/bits/wordsize.h \
       /usr/include/x86_64-linux-gnu/gnu/stubs.h \
       /usr/include/x86_64-linux-gnu/gnu/stubs-64.h \
       /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h \
      
      After:
      
      $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/
      
      Auto-detecting system features:
      ...                        libelf: [ on  ]
      ...                           bpf: [ on  ]
      
        HOSTCC   /tmp/bld/fixdep.o
        HOSTLD   /tmp/bld/fixdep-in.o
        LINK     /tmp/bld/fixdep
        CC       /tmp/bld/libbpf.o
        CC       /tmp/bld/bpf.o
        CC       /tmp/bld/nlattr.o
        CC       /tmp/bld/btf.o
        CC       /tmp/bld/libbpf_errno.o
        CC       /tmp/bld/str_error.o
        CC       /tmp/bld/netlink.o
        CC       /tmp/bld/bpf_prog_linfo.o
        CC       /tmp/bld/libbpf_probes.o
        CC       /tmp/bld/xsk.o
        LD       /tmp/bld/libbpf-in.o
        LINK     /tmp/bld/libbpf.a
        LINK     /tmp/bld/libbpf.so
        LINK     /tmp/bld/test_libbpf
      
      $ head /tmp/bld/.libbpf.o.cmd
      cmd_/tmp/bld/libbpf.o := gcc -Wp,-MD,/tmp/bld/.libbpf.o.d -Wp,-MT,/tmp/bld/libbpf.o -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Werror -Wall -fPIC -I. -I/usr/local/google/home/sdf/src/linux/tools/include -I/usr/local/google/home/sdf/src/linux/tools/arch/x86/include/uapi -I/usr/local/google/home/sdf/src/linux/tools/include/uapi -fvisibility=hidden -D"BUILD_STR(s)=$(pound)s" -c -o /tmp/bld/libbpf.o libbpf.c
      
      source_/tmp/bld/libbpf.o := libbpf.c
      
      deps_/tmp/bld/libbpf.o := \
        /usr/include/stdc-predef.h \
        /usr/include/stdlib.h \
        /usr/include/features.h \
        /usr/include/x86_64-linux-gnu/sys/cdefs.h \
        /usr/include/x86_64-linux-gnu/bits/wordsize.h \
      
      Fixes: 7c422f55 ("tools build: Build fixdep helper from perf and basic libs")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      8e268887
  10. 01 3月, 2019 7 次提交
  11. 28 2月, 2019 2 次提交
  12. 26 2月, 2019 1 次提交
    • M
      libbpf: add support for using AF_XDP sockets · 1cad0788
      Magnus Karlsson 提交于
      This commit adds AF_XDP support to libbpf. The main reason for this is
      to facilitate writing applications that use AF_XDP by offering
      higher-level APIs that hide many of the details of the AF_XDP
      uapi. This is in the same vein as libbpf facilitates XDP adoption by
      offering easy-to-use higher level interfaces of XDP
      functionality. Hopefully this will facilitate adoption of AF_XDP, make
      applications using it simpler and smaller, and finally also make it
      possible for applications to benefit from optimizations in the AF_XDP
      user space access code. Previously, people just copied and pasted the
      code from the sample application into their application, which is not
      desirable.
      
      The interface is composed of two parts:
      
      * Low-level access interface to the four rings and the packet
      * High-level control plane interface for creating and setting
        up umems and af_xdp sockets as well as a simple XDP program.
      Tested-by: NBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: NMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      1cad0788
  13. 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
  14. 15 2月, 2019 3 次提交
    • A
      libbpf: Introduce bpf_object__btf · 789f6bab
      Andrey Ignatov 提交于
      Add new accessor for bpf_object to get opaque struct btf * from it.
      
      struct btf * is needed for all operations with BTF and it's present in
      bpf_object. The only thing missing is a way to get it.
      
      Example use-case is to get BTF key_type_id and value_type_id for a map in
      bpf_object. It can be done with btf__get_map_kv_tids() but that function
      requires struct btf *.
      
      Similar API can be added for struct btf_ext but no use-case for it yet.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      789f6bab
    • A
      libbpf: Introduce bpf_map__resize · 1a11a4c7
      Andrey Ignatov 提交于
      Add bpf_map__resize() to change max_entries for a map.
      
      Quite often necessary map size is unknown at compile time and can be
      calculated only at run time.
      
      Currently the following approach is used to do so:
      * bpf_object__open_buffer() to open Elf file from a buffer;
      * bpf_object__find_map_by_name() to find relevant map;
      * bpf_map__def() to get map attributes and create struct
        bpf_create_map_attr from them;
      * update max_entries in bpf_create_map_attr;
      * bpf_create_map_xattr() to create new map with updated max_entries;
      * bpf_map__reuse_fd() to replace the map in bpf_object with newly
        created one.
      
      And after all this bpf_object can finally be loaded. The map will have
      new size.
      
      It 1) is quite a lot of steps; 2) doesn't take BTF into account.
      
      For "2)" even more steps should be made and some of them require changes
      to libbpf (e.g. to get struct btf * from bpf_object).
      
      Instead the whole problem can be solved by introducing simple
      bpf_map__resize() API that checks the map and sets new max_entries if
      the map is not loaded yet.
      
      So the new steps are:
      * bpf_object__open_buffer() to open Elf file from a buffer;
      * bpf_object__find_map_by_name() to find relevant map;
      * bpf_map__resize() to update max_entries.
      
      That's much simpler and works with BTF.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      1a11a4c7
    • A
      tools/bpf: replace bzero with memset · 1ad9cbb8
      Andrii Nakryiko 提交于
      bzero() call is deprecated and superseded by memset().
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Reported-by: NDavid Laight <david.laight@aculab.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      1ad9cbb8
  15. 09 2月, 2019 4 次提交
  16. 08 2月, 2019 2 次提交
    • Y
      tools/bpf: add log_level to bpf_load_program_attr · a4021a35
      Yonghong Song 提交于
      The kernel verifier has three levels of logs:
          0: no logs
          1: logs mostly useful
        > 1: verbose
      
      Current libbpf API functions bpf_load_program_xattr() and
      bpf_load_program() cannot specify log_level.
      The bcc, however, provides an interface for user to
      specify log_level 2 for verbose output.
      
      This patch added log_level into structure
      bpf_load_program_attr, so users, including bcc, can use
      bpf_load_program_xattr() to change log_level. The
      supported log_level is 0, 1, and 2.
      
      The bpf selftest test_sock.c is modified to enable log_level = 2.
      If the "verbose" in test_sock.c is changed to true,
      the test will output logs like below:
        $ ./test_sock
        func#0 @0
        0: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
        0: (bf) r6 = r1
        1: R1=ctx(id=0,off=0,imm=0) R6_w=ctx(id=0,off=0,imm=0) R10=fp0,call_-1
        1: (61) r7 = *(u32 *)(r6 +28)
        invalid bpf_context access off=28 size=4
      
        Test case: bind4 load with invalid access: src_ip6 .. [PASS]
        ...
        Test case: bind6 allow all .. [PASS]
        Summary: 16 PASSED, 0 FAILED
      
      Some test_sock tests are negative tests and verbose verifier
      log will be printed out as shown in the above.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      a4021a35
    • A
      tools/bpf: add missing strings.h include · 62b8cea6
      Andrii Nakryiko 提交于
      Few files in libbpf are using bzero() function (defined in strings.h header), but
      don't include corresponding header. When libbpf is added as a dependency to pahole,
      this undeterministically causes warnings on some machines:
      
      bpf.c:225:2: warning: implicit declaration of function 'bzero' [-Wimplicit-function-declaration]
        bzero(&attr, sizeof(attr));
          ^~~~~
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      62b8cea6
  17. 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
  18. 05 2月, 2019 7 次提交