1. 12 Feb, 2019 1 commit
  2. 26 Jan, 2019 2 commits
    • Arnaldo Carvalho de Melo's avatar
      tools lib subcmd: Don't add the kernel sources to the include path · dfa71e42
      Arnaldo Carvalho de Melo authored
      [ Upstream commit ece98049 ]
      
      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: 's avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: 's avatarJiri 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: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      dfa71e42
    • Adrian Hunter's avatar
      tools lib traceevent: Fix compile warnings in tools/lib/traceevent/event-parse.c · 7dd70b09
      Adrian Hunter authored
      [ Upstream commit 0631ca3a ]
      
      Fix following warnings:
      
        event-parse.c: In function ‘tep_find_event_by_name’:
        event-parse.c:3521:21: warning: ‘event’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          pevent->last_event = event;
          ~~~~~~~~~~~~~~~~~~~^~~~~~~
          CC       ui/gtk/hists.o
          LINK     plugin_mac80211.so
          CC       nlattr.o
        event-parse.c: In function ‘tep_data_lat_fmt’:
        event-parse.c:5200:4: warning: ‘migrate_disable’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", migrate_disable);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:5207:4: warning: ‘lock_depth’ may be used uninitialized in this function [-Wmaybe-uninitialized]
            trace_seq_printf(s, "%d", lock_depth);
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          LINK     plugin_sched_switch.so
          LINK     plugin_function.so
          LINK     plugin_xen.so
        event-parse.c: In function ‘tep_event_info’:
        event-parse.c:5047:7: warning: ‘len_arg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
               trace_seq_printf(s, format, len_arg, (char)val);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4884:6: note: ‘len_arg’ was declared here
          int len_arg;
              ^~~~~~~
        event-parse.c:4338:11: warning: ‘vsize’ may be used uninitialized in this function [-Wmaybe-uninitialized]
             val = tep_read_number(pevent, bptr, vsize);
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        event-parse.c:4224:6: note: ‘vsize’ was declared here
          int vsize;
              ^~~~~
      
      $ gcc --version
        gcc (Clear Linux OS for Intel Architecture) 8.2.1 20180502
      Signed-off-by: 's avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
      Link: http://lkml.kernel.org/r/20181122112937.10582-1-adrian.hunter@intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      7dd70b09
  3. 09 Jan, 2019 1 commit
  4. 31 Oct, 2018 1 commit
  5. 21 Oct, 2018 1 commit
    • Daniel Borkmann's avatar
      bpf, libbpf: simplify and cleanup perf ring buffer walk · 3dca2115
      Daniel Borkmann authored
      Simplify bpf_perf_event_read_simple() a bit and fix up some minor
      things along the way: the return code in the header is not of type
      int but enum bpf_perf_event_ret instead. Once callback indicated
      to break the loop walking event data, it also needs to be consumed
      in data_tail since it has been processed already.
      
      Moreover, bpf_perf_event_print_t callback should avoid void * as
      we actually get a pointer to struct perf_event_header and thus
      applications can make use of container_of() to have type checks.
      The walk also doesn't have to use modulo op since the ring size is
      required to be power of two.
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      3dca2115
  6. 19 Oct, 2018 3 commits
  7. 16 Oct, 2018 2 commits
  8. 15 Oct, 2018 1 commit
    • John Fastabend's avatar
      bpf: bpftool, add flag to allow non-compat map definitions · c034a177
      John Fastabend authored
      Multiple map definition structures exist and user may have non-zero
      fields in their definition that are not recognized by bpftool and
      libbpf. The normal behavior is to then fail loading the map. Although
      this is a good default behavior users may still want to load the map
      for debugging or other reasons. This patch adds a --mapcompat flag
      that can be used to override the default behavior and allow loading
      the map even when it has additional non-zero fields.
      
      For now the only user is 'bpftool prog' we can switch over other
      subcommands as needed. The library exposes an API that consumes
      a flags field now but I kept the original API around also in case
      users of the API don't want to expose this. The flags field is an
      int in case we need more control over how the API call handles
      errors/features/etc in the future.
      Signed-off-by: 's avatarJohn Fastabend <john.fastabend@gmail.com>
      Acked-by: 's avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      c034a177
  9. 10 Oct, 2018 1 commit
  10. 08 Oct, 2018 3 commits
  11. 04 Oct, 2018 6 commits
    • Andrey Ignatov's avatar
      libbpf: Use __u32 instead of u32 in bpf_program__load · e5b0863c
      Andrey Ignatov authored
      Make bpf_program__load consistent with other interfaces: use __u32
      instead of u32. That in turn fixes build of samples:
      
      In file included from ./samples/bpf/trace_output_user.c:21:0:
      ./tools/lib/bpf/libbpf.h:132:9: error: unknown type name ‘u32’
               u32 kern_version);
               ^
      
      Fixes: commit 29cd77f4 ("libbpf: Support loading individual progs")
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      e5b0863c
    • Andrey Ignatov's avatar
      libbpf: Make include guards consistent · eff81908
      Andrey Ignatov authored
      Rename include guards to have consistent names "__LIBBPF_<header_name>".
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      eff81908
    • Andrey Ignatov's avatar
      libbpf: Consistent prefixes for interfaces in str_error.h. · 24d6a808
      Andrey Ignatov authored
      libbpf is used more and more outside kernel tree. That means the library
      should follow good practices in library design and implementation to
      play well with third party code that uses it.
      
      One of such practices is to have a common prefix (or a few) for every
      interface, function or data structure, library provides. I helps to
      avoid name conflicts with other libraries and keeps API consistent.
      
      Inconsistent names in libbpf already cause problems in real life. E.g.
      an application can't use both libbpf and libnl due to conflicting
      symbols.
      
      Having common prefix will help to fix current and avoid future problems.
      
      libbpf already uses the following prefixes for its interfaces:
      * bpf_ for bpf system call wrappers, program/map/elf-object
        abstractions and a few other things;
      * btf_ for BTF related API;
      * libbpf_ for everything else.
      
      The patch renames function in str_error.h to have libbpf_ prefix since it
      misses one and doesn't fit well into the first two categories.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      24d6a808
    • Andrey Ignatov's avatar
      libbpf: Consistent prefixes for interfaces in nlattr.h. · f04bc8a4
      Andrey Ignatov authored
      libbpf is used more and more outside kernel tree. That means the library
      should follow good practices in library design and implementation to
      play well with third party code that uses it.
      
      One of such practices is to have a common prefix (or a few) for every
      interface, function or data structure, library provides. I helps to
      avoid name conflicts with other libraries and keeps API consistent.
      
      Inconsistent names in libbpf already cause problems in real life. E.g.
      an application can't use both libbpf and libnl due to conflicting
      symbols.
      
      Having common prefix will help to fix current and avoid future problems.
      
      libbpf already uses the following prefixes for its interfaces:
      * bpf_ for bpf system call wrappers, program/map/elf-object
        abstractions and a few other things;
      * btf_ for BTF related API;
      * libbpf_ for everything else.
      
      The patch adds libbpf_ prefix to interfaces in nlattr.h that use none of
      mentioned above prefixes and doesn't fit well into the first two
      categories.
      
      Since affected part of API is used in bpftool, the patch applies
      corresponding change to bpftool as well. Having it in a separate patch
      will cause a state of tree where bpftool is broken what may not be a
      good idea.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      f04bc8a4
    • Andrey Ignatov's avatar
      libbpf: Consistent prefixes for interfaces in libbpf.h. · aae57780
      Andrey Ignatov authored
      libbpf is used more and more outside kernel tree. That means the library
      should follow good practices in library design and implementation to
      play well with third party code that uses it.
      
      One of such practices is to have a common prefix (or a few) for every
      interface, function or data structure, library provides. I helps to
      avoid name conflicts with other libraries and keeps API consistent.
      
      Inconsistent names in libbpf already cause problems in real life. E.g.
      an application can't use both libbpf and libnl due to conflicting
      symbols.
      
      Having common prefix will help to fix current and avoid future problems.
      
      libbpf already uses the following prefixes for its interfaces:
      * bpf_ for bpf system call wrappers, program/map/elf-object
        abstractions and a few other things;
      * btf_ for BTF related API;
      * libbpf_ for everything else.
      
      The patch adds libbpf_ prefix to functions and typedef in libbpf.h that
      use none of mentioned above prefixes and doesn't fit well into the first
      two categories.
      
      Since affected part of API is used in bpftool, the patch applies
      corresponding change to bpftool as well. Having it in a separate patch
      will cause a state of tree where bpftool is broken what may not be a
      good idea.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      aae57780
    • Andrey Ignatov's avatar
      libbpf: Move __dump_nlmsg_t from API to implementation · 434fe9d4
      Andrey Ignatov authored
      This typedef is used only by implementation in netlink.c. Nothing uses
      it in public API. Move it to netlink.c.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      434fe9d4
  12. 03 Oct, 2018 1 commit
  13. 27 Sep, 2018 3 commits
    • Andrey Ignatov's avatar
      libbpf: Support sk_skb/stream_{parser, verdict} section names · c6f6851b
      Andrey Ignatov authored
      Add section names for BPF_SK_SKB_STREAM_PARSER and
      BPF_SK_SKB_STREAM_VERDICT attach types to be able to identify them in
      libbpf_attach_type_by_name.
      
      "stream_parser" and "stream_verdict" are used instead of simple "parser"
      and "verdict" just to avoid possible confusion in a place where attach
      type is used alone (e.g. in bpftool's show sub-commands) since there is
      another attach point that can be named as "verdict": BPF_SK_MSG_VERDICT.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      c6f6851b
    • Andrey Ignatov's avatar
      libbpf: Support cgroup_skb/{e,in}gress section names · bafa7afe
      Andrey Ignatov authored
      Add section names for BPF_CGROUP_INET_INGRESS and BPF_CGROUP_INET_EGRESS
      attach types to be able to identify them in libbpf_attach_type_by_name.
      
      "cgroup_skb" is used instead of "cgroup/skb" mostly to easy possible
      unifying of how libbpf and bpftool works with section names:
      * bpftool uses "cgroup_skb" to in "prog list" sub-command;
      * bpftool uses "ingress" and "egress" in "cgroup list" sub-command;
      * having two parts instead of three in a string like "cgroup_skb/ingress"
        can be leveraged to split it to prog_type part and attach_type part,
        or vise versa: use two parts to make a section name.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      bafa7afe
    • Andrey Ignatov's avatar
      libbpf: Introduce libbpf_attach_type_by_name · 956b620f
      Andrey Ignatov authored
      There is a common use-case when ELF object contains multiple BPF
      programs and every program has its own section name. If it's cgroup-bpf
      then programs have to be 1) loaded and 2) attached to a cgroup.
      
      It's convenient to have information necessary to load BPF program
      together with program itself. This is where section name works fine in
      conjunction with libbpf_prog_type_by_name that identifies prog_type and
      expected_attach_type and these can be used with BPF_PROG_LOAD.
      
      But there is currently no way to identify attach_type by section name
      and it leads to messy code in user space that reinvents guessing logic
      every time it has to identify attach type to use with BPF_PROG_ATTACH.
      
      The patch introduces libbpf_attach_type_by_name that guesses attach type
      by section name if a program can be attached.
      
      The difference between expected_attach_type provided by
      libbpf_prog_type_by_name and attach_type provided by
      libbpf_attach_type_by_name is the former is used at BPF_PROG_LOAD time
      and can be zero if a program of prog_type X has only one corresponding
      attach type Y whether the latter provides specific attach type to use
      with BPF_PROG_ATTACH.
      
      No new section names were added to section_names array. Only existing
      ones were reorganized and attach_type was added where appropriate.
      Signed-off-by: 's avatarAndrey Ignatov <rdna@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      956b620f
  14. 19 Sep, 2018 14 commits