1. 27 12月, 2019 7 次提交
    • Y
      tools/bpf: make libbpf _GNU_SOURCE friendly · b5cb45f6
      Yonghong Song 提交于
      [ Upstream commit b4269954 ]
      
      During porting libbpf to bcc, I got some warnings like below:
        ...
        [  2%] Building C object src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf.c.o
        /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf.c:12:0:
        warning: "_GNU_SOURCE" redefined [enabled by default]
         #define _GNU_SOURCE
        ...
        [  3%] Building C object src/cc/CMakeFiles/bpf-shared.dir/libbpf/src/libbpf_errno.c.o
        /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf_errno.c: In function ‘libbpf_strerror’:
        /home/yhs/work/bcc2/src/cc/libbpf/src/libbpf_errno.c:45:7:
        warning: assignment makes integer from pointer without a cast [enabled by default]
           ret = strerror_r(err, buf, size);
        ...
      
      bcc is built with _GNU_SOURCE defined and this caused the above warning.
      This patch intends to make libpf _GNU_SOURCE friendly by
        . define _GNU_SOURCE in libbpf.c unless it is not defined
        . undefine _GNU_SOURCE as non-gnu version of strerror_r is expected.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Acked-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      b5cb45f6
    • L
      bpf: libbpf: retry loading program on EAGAIN · c3547ca0
      Lorenz Bauer 提交于
      [ Upstream commit 86edaed3 ]
      
      Commit c3494801 ("bpf: check pending signals while
      verifying programs") makes it possible for the BPF_PROG_LOAD
      to fail with EAGAIN. Retry unconditionally in this case.
      
      Fixes: c3494801 ("bpf: check pending signals while verifying programs")
      Signed-off-by: NLorenz Bauer <lmb@cloudflare.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      c3547ca0
    • L
      bpf, libbpf, smatch: Fix potential NULL pointer dereference · 4c231697
      Leo Yan 提交于
      [ Upstream commit 33bae185 ]
      
      Based on the following report from Smatch, fix the potential NULL
      pointer dereference check:
      
        tools/lib/bpf/libbpf.c:3493
        bpf_prog_load_xattr() warn: variable dereferenced before check 'attr'
        (see line 3483)
      
        3479 int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
        3480                         struct bpf_object **pobj, int *prog_fd)
        3481 {
        3482         struct bpf_object_open_attr open_attr = {
        3483                 .file           = attr->file,
        3484                 .prog_type      = attr->prog_type,
                                               ^^^^^^
        3485         };
      
      At the head of function, it directly access 'attr' without checking
      if it's NULL pointer. This patch moves the values assignment after
      validating 'attr' and 'attr->file'.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      4c231697
    • D
      libbpf: fix samples/bpf build failure due to undefined UINT32_MAX · 8a254f79
      Daniel T. Lee 提交于
      [ Upstream commit 32e621e5 ]
      
      Currently, building bpf samples will cause the following error.
      
          ./tools/lib/bpf/bpf.h:132:27: error: 'UINT32_MAX' undeclared here (not in a function) ..
           #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in kernels <= 5.1 */
                                     ^
          ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro 'BPF_LOG_BUF_SIZE'
           extern char bpf_log_buf[BPF_LOG_BUF_SIZE];
                                   ^~~~~~~~~~~~~~~~
      
      Due to commit 4519efa6 ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error")
      hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is
      defined in <stdint.h> header.
      
      Even with this change, bpf selftests are running fine since these are built
      with clang and it includes header(-idirafter) from clang/6.0.0/include.
      (it has <stdint.h>)
      
          clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \
          -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \
          -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \
          llc -march=bpf -mcpu=generic  -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o
      
      But bpf samples are compiled with GCC, and it only searches and includes
      headers declared at the target file. As '#include <stdint.h>' hasn't been
      declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples.
      
          gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes \
          -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ \
          -I./tools/  lib/ -I./tools/include -I./tools/perf -c -o ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c;
      
      This commit add declaration of '#include <stdint.h>' to tools/lib/bpf/bpf.h
      to fix this problem.
      Signed-off-by: NDaniel T. Lee <danieltimlee@gmail.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      8a254f79
    • V
      tools/bpf: fix perf build error with uClibc (seen on ARC) · 9166c518
      Vineet Gupta 提交于
      [ Upstream commit ca31ca82 ]
      
      When build perf for ARC recently, there was a build failure due to lack
      of __NR_bpf.
      
      | Auto-detecting system features:
      |
      | ...                     get_cpuid: [ OFF ]
      | ...                           bpf: [ on  ]
      |
      | #  error __NR_bpf not defined. libbpf does not support your arch.
          ^~~~~
      | bpf.c: In function 'sys_bpf':
      | bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function)
      |  return syscall(__NR_bpf, cmd, attr, size);
      |                 ^~~~~~~~
      |                 sys_bpf
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      9166c518
    • S
      libbpf: force fixdep compilation at the start of the build · 1fb53d7e
      Stanislav Fomichev 提交于
      [ Upstream commit 8e268887 ]
      
      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>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      1fb53d7e
    • S
      bpf: libbpf: retry map creation without the name · 5c795afb
      Stanislav Fomichev 提交于
      [ Upstream commit 23499442 ]
      
      Since commit 88cda1c9 ("bpf: libbpf: Provide basic API support
      to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name
      for maps. Pre v4.14 kernels don't know about map names and return an
      error about unexpected non-zero data. Retry sys_bpf without a map
      name to cover older kernels.
      
      v2 changes:
      * check for errno == EINVAL as suggested by Daniel Borkmann
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      5c795afb
  2. 18 9月, 2018 1 次提交
    • A
      tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems · 6d41907c
      Arnaldo Carvalho de Melo 提交于
      Same problem that got fixed in a similar fashion in tools/perf/ in
      c8b5f2c9 ("tools: Introduce str_error_r()"), fix it in the same
      way, licensing needs to be sorted out to libbpf to use libapi, so,
      for this simple case, just get the same wrapper in tools/lib/bpf.
      
      This makes libbpf and its users (bpftool, selftests, perf) to build
      again in Alpine Linux 3.[45678] and edge.
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Quentin Monnet <quentin.monnet@netronome.com>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Yonghong Song <yhs@fb.com>
      Fixes: 1ce6a9fc ("bpf: fix build error in libbpf with EXTRA_CFLAGS="-Wp, -D_FORTIFY_SOURCE=2 -O2"")
      Link: https://lkml.kernel.org/r/20180917151636.GA21790@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6d41907c
  3. 11 8月, 2018 2 次提交
  4. 06 8月, 2018 1 次提交
  5. 03 8月, 2018 1 次提交
  6. 31 7月, 2018 1 次提交
  7. 29 7月, 2018 1 次提交
    • T
      perf build: Build error in libbpf missing initialization · b611da43
      Thomas Richter 提交于
      In linux-next tree compiling the perf tool with additional make flags
      EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2" causes a compiler error.
      It is the warning 'variable may be used uninitialized' which is treated
      as error: I compile it using a FEDORA 28 installation, my gcc compiler
      version: gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20). The file that
      causes the error is tools/lib/bpf/libbpf.c.
      
        [root@p23lp27] # make V=1 EXTRA_CFLAGS="-Wp,-D_FORTIFY_SOURCE=2 -O2"
        [...]
        Makefile.config:849: No openjdk development package found, please
           install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
        Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h'
                differs from latest version at 'include/uapi/linux/if_link.h'
          CC       libbpf.o
        libbpf.c: In function ‘bpf_perf_event_read_simple’:
        libbpf.c:2342:6: error: ‘ret’ may be used uninitialized in this
        			function [-Werror=maybe-uninitialized]
          int ret;
              ^
        cc1: all warnings being treated as errors
        mv: cannot stat './.libbpf.o.tmp': No such file or directory
        /home6/tmricht/linux-next/tools/build/Makefile.build:96: recipe for target 'libbpf.o' failed
      Suggested-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      b611da43
  8. 27 7月, 2018 2 次提交
  9. 25 7月, 2018 2 次提交
  10. 17 7月, 2018 1 次提交
  11. 14 7月, 2018 1 次提交
  12. 12 7月, 2018 6 次提交
  13. 01 7月, 2018 4 次提交
  14. 30 5月, 2018 1 次提交
  15. 28 5月, 2018 2 次提交
  16. 25 5月, 2018 1 次提交
  17. 24 5月, 2018 2 次提交
    • M
      ipv6: sr: Add seg6local action End.BPF · 004d4b27
      Mathieu Xhonneux 提交于
      This patch adds the End.BPF action to the LWT seg6local infrastructure.
      This action works like any other seg6local End action, meaning that an IPv6
      header with SRH is needed, whose DA has to be equal to the SID of the
      action. It will also advance the SRH to the next segment, the BPF program
      does not have to take care of this.
      
      Since the BPF program may not be a source of instability in the kernel, it
      is important to ensure that the integrity of the packet is maintained
      before yielding it back to the IPv6 layer. The hook hence keeps track if
      the SRH has been altered through the helpers, and re-validates its
      content if needed with seg6_validate_srh. The state kept for validation is
      stored in a per-CPU buffer. The BPF program is not allowed to directly
      write into the packet, and only some fields of the SRH can be altered
      through the helper bpf_lwt_seg6_store_bytes.
      
      Performances profiling has shown that the SRH re-validation does not induce
      a significant overhead. If the altered SRH is deemed as invalid, the packet
      is dropped.
      
      This validation is also done before executing any action through
      bpf_lwt_seg6_action, and will not be performed again if the SRH is not
      modified after calling the action.
      
      The BPF program may return 3 types of return codes:
          - BPF_OK: the End.BPF action will look up the next destination through
                   seg6_lookup_nexthop.
          - BPF_REDIRECT: if an action has been executed through the
                bpf_lwt_seg6_action helper, the BPF program should return this
                value, as the skb's destination is already set and the default
                lookup should not be performed.
          - BPF_DROP : the packet will be dropped.
      Signed-off-by: NMathieu Xhonneux <m.xhonneux@gmail.com>
      Acked-by: NDavid Lebrun <dlebrun@google.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      004d4b27
    • S
      tools/lib/libbpf.c: fix string format to allow build on arm32 · a1c81810
      Sirio Balmelli 提交于
      On arm32, 'cd tools/testing/selftests/bpf && make' fails with:
      
      libbpf.c:80:10: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long long int}’ [-Werror=format=]
         (func)("libbpf: " fmt, ##__VA_ARGS__); \
                ^
      libbpf.c:83:30: note: in expansion of macro ‘__pr’
       #define pr_warning(fmt, ...) __pr(__pr_warning, fmt, ##__VA_ARGS__)
                                    ^~~~
      libbpf.c:1072:3: note: in expansion of macro ‘pr_warning’
         pr_warning("map:%s value_type:%s has BTF type_size:%ld != value_size:%u\n",
      
      To fix, typecast 'key_size' and amend format string.
      Signed-off-by: NSirio Balmelli <sirio@b-ad.ch>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      a1c81810
  18. 23 5月, 2018 1 次提交
  19. 17 5月, 2018 1 次提交
  20. 11 5月, 2018 2 次提交