1. 12 10月, 2019 2 次提交
  2. 05 10月, 2019 1 次提交
  3. 01 10月, 2019 1 次提交
  4. 26 7月, 2019 1 次提交
    • L
      bpf, libbpf, smatch: Fix potential NULL pointer dereference · ef5b2043
      Leo Yan 提交于
      [ Upstream commit 33bae185f74d49a0d7b1bfaafb8e959efce0f243 ]
      
      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>
      ef5b2043
  5. 31 5月, 2019 2 次提交
    • D
      libbpf: fix samples/bpf build failure due to undefined UINT32_MAX · 0cbef22f
      Daniel T. Lee 提交于
      [ Upstream commit 32e621e55496a0009f44fe4914cd4a23cade4984 ]
      
      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 4519efa6f8ea ("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>
      0cbef22f
    • V
      tools/bpf: fix perf build error with uClibc (seen on ARC) · f3ed010f
      Vineet Gupta 提交于
      [ Upstream commit ca31ca8247e2d3807ff5fa1d1760616a2292001c ]
      
      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>
      f3ed010f
  6. 17 5月, 2019 1 次提交
    • R
      tools lib traceevent: Fix missing equality check for strcmp · 7d4d8683
      Rikard Falkeborn 提交于
      [ Upstream commit f32c2877bcb068a718bb70094cd59ccc29d4d082 ]
      
      There was a missing comparison with 0 when checking if type is "s64" or
      "u64". Therefore, the body of the if-statement was entered if "type" was
      "u64" or not "s64", which made the first strcmp() redundant since if
      type is "u64", it's not "s64".
      
      If type is "s64", the body of the if-statement is not entered but since
      the remainder of the function consists of if-statements which will not
      be entered if type is "s64", we will just return "val", which is
      correct, albeit at the cost of a few more calls to strcmp(), i.e., it
      will behave just as if the if-statement was entered.
      
      If type is neither "s64" or "u64", the body of the if-statement will be
      entered incorrectly and "val" returned. This means that any type that is
      checked after "s64" and "u64" is handled the same way as "s64" and
      "u64", i.e., the limiting of "val" to fit in for example "s8" is never
      reached.
      
      This was introduced in the kernel tree when the sources were copied from
      trace-cmd in commit f7d82350 ("tools/events: Add files to create
      libtraceevent.a"), and in the trace-cmd repo in 1cdbae6035cei
      ("Implement typecasting in parser") when the function was introduced,
      i.e., it has always behaved the wrong way.
      
      Detected by cppcheck.
      Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
      Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov <tstoyanov@vmware.com>
      Fixes: f7d82350 ("tools/events: Add files to create libtraceevent.a")
      Link: http://lkml.kernel.org/r/20190409091529.2686-1-rikard.falkeborn@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7d4d8683
  7. 06 4月, 2019 2 次提交
    • T
      tools lib traceevent: Fix buffer overflow in arg_eval · 224c996e
      Tony Jones 提交于
      [ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ]
      
      Fix buffer overflow observed when running perf test.
      
      The overflow is when trying to evaluate "1ULL << (64 - 1)" which is
      resulting in -9223372036854775808 which overflows the 20 character
      buffer.
      
      If is possible this bug has been reported before but I still don't see
      any fix checked in:
      
      See: https://www.spinics.net/lists/linux-perf-users/msg07714.htmlReported-by: NMichael Sartain <mikesart@fastmail.com>
      Reported-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NTony Jones <tonyj@suse.de>
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Fixes: f7d82350 ("tools/events: Add files to create libtraceevent.a")
      Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.deSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      224c996e
    • S
      libbpf: force fixdep compilation at the start of the build · e21f655c
      Stanislav Fomichev 提交于
      [ Upstream commit 8e2688876c7f7073d925e1f150e86b8ed3338f52 ]
      
      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>
      e21f655c
  8. 13 2月, 2019 1 次提交
  9. 26 1月, 2019 1 次提交
    • A
      tools lib subcmd: Don't add the kernel sources to the include path · d9513fdb
      Arnaldo Carvalho de Melo 提交于
      [ Upstream commit ece9804985b57e1ccd83b1fb6288520955a29d51 ]
      
      At some point we decided not to directly include kernel sources files
      when building tools/perf/, but when tools/lib/subcmd/ was forked from
      tools/perf it somehow ended up adding it via these two lines in its
      Makefile:
      
        CFLAGS += -I$(srctree)/include/uapi
        CFLAGS += -I$(srctree)/include
      
      As $(srctree) points to the kernel sources.
      
      Removing those lines and keeping just:
      
        CFLAGS += -I$(srctree)/tools/include/
      
      Is enough to build tools/perf and tools/objtool.
      
      This fixes the build when building from the sources in environments such
      as the Android NDK crossbuilding from a fedora:26 system:
      
        subcmd-util.h:11:15: error: expected ',' or ';' before 'void'
         static inline void report(const char *prefix, const char *err, va_list params)
                       ^
        In file included from /git/perf/include/uapi/linux/stddef.h:2:0,
                         from /git/perf/include/uapi/linux/posix_types.h:5,
                         from /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/sys/types.h:36,
                         from /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/unistd.h:33,
                         from run-command.c:2:
        subcmd-util.h:18:17: error: '__no_instrument_function__' attribute applies only to functions
      
      The /opt/android-ndk-r12b/platforms/android-24/arch-arm/usr/include/sys/types.h
      file that includes linux/posix_types.h ends up getting the one in the kernel
      sources causing the breakage. Fix it.
      
      Test built tools/objtool/ too.
      Reported-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 4b6ab94e ("perf subcmd: Create subcmd library")
      Link: https://lkml.kernel.org/n/tip-5lhaoecrj12t0bqwvpiu14sm@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d9513fdb
  10. 10 1月, 2019 1 次提交
  11. 16 10月, 2018 1 次提交
    • J
      perf tools: Fix tracing_path_mount proper path · c458a620
      Jiri Olsa 提交于
      If there's no tracefs (RHEL7) support the tracing_path_mount
      returns debugfs path which results in following fail:
      
        # perf probe sys_write
        kprobe_events file does not exist - please rebuild kernel with CONFIG_KPROBE_EVENTS.
        Error: Failed to add events.
      
      In tracing_path_debugfs_mount function we need to return the
      'tracing' path instead of just the mount to make it work:
      
        # perf probe sys_write
        Added new event:
          probe:sys_write      (on sys_write)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe:sys_write -aR sleep 1
      
      Adding the 'return tracing_path;' also to tracing_path_tracefs_mount
      function just for consistency with tracing_path_debugfs_mount.
      
      Upstream keeps working, because it has the tracefs support.
      
      Link: http://lkml.kernel.org/n/tip-yiwkzexq9fk1ey1xg3gnjlw4@git.kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Fixes: 23773ca1 ("perf tools: Make perf aware of tracefs")
      Link: http://lkml.kernel.org/r/20181016114818.3595-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c458a620
  12. 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
  13. 20 8月, 2018 1 次提交
  14. 14 8月, 2018 23 次提交
  15. 11 8月, 2018 1 次提交