1. 07 6月, 2016 7 次提交
  2. 26 1月, 2016 1 次提交
    • W
      perf bpf: Check relocation target section · 666810e8
      Wang Nan 提交于
      Libbpf should check the target section before doing relocation to ensure
      the relocation is correct. If not, a bug in LLVM causes an error. See
      [1].  Also, if an incorrect BPF script uses both global variable and
      map, global variable whould be treated as map and be relocated without
      error.
      
      This patch saves the id of the map section into obj->efile and compare
      target section of a relocation symbol against it during relocation.
      
      Previous patch introduces a test case about this problem.  After this
      patch:
      
        # ~/perf test BPF
        37: Test BPF filter                                          :
        37.1: Test basic BPF filtering                               : Ok
        37.2: Test BPF prologue generation                           : Ok
        37.3: Test BPF relocation checker                            : Ok
      
        # perf test -v BPF
        ...
        37.3: Test BPF relocation checker                            :
        ...
        libbpf: loading object '[bpf_relocation_test]' from buffer
        libbpf: section .strtab, size 126, link 0, flags 0, type=3
        libbpf: section .text, size 0, link 0, flags 6, type=1
        libbpf: section .data, size 0, link 0, flags 3, type=1
        libbpf: section .bss, size 0, link 0, flags 3, type=8
        libbpf: section func=sys_write, size 104, link 0, flags 6, type=1
        libbpf: found program func=sys_write
        libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9
        libbpf: section maps, size 16, link 0, flags 3, type=1
        libbpf: maps in [bpf_relocation_test]: 16 bytes
        libbpf: section license, size 4, link 0, flags 3, type=1
        libbpf: license of [bpf_relocation_test] is GPL
        libbpf: section version, size 4, link 0, flags 3, type=1
        libbpf: kernel version of [bpf_relocation_test] is 40400
        libbpf: section .symtab, size 144, link 1, flags 0, type=2
        libbpf: map 0 is "my_table"
        libbpf: collecting relocating info for: 'func=sys_write'
        libbpf: Program 'func=sys_write' contains non-map related relo data pointing to section 65522
        bpf: failed to load buffer
        Compile BPF program failed.
        test child finished with 0
        ---- end ----
        Test BPF filter subtest 2: Ok
      
      [1] https://llvm.org/bugs/show_bug.cgi?id=26243Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1453715801-7732-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      666810e8
  3. 11 12月, 2015 2 次提交
    • W
      tools lib bpf: Fetch map names from correct strtab · 77ba9a5b
      Wang Nan 提交于
      Namhyung Kim pointed out a potential problem in original code that it
      fetches names of maps from section header string table, which is used
      to store section names.
      
      Original code doesn't cause error because of a LLVM behavior that, it
      combines shstrtab into strtab. For example:
      
       $ echo 'int func() {return 0;}' | x86_64-oe-linux-clang -x c -o temp.o -c -
       $ readelf -h ./temp.o
       ELF Header:
         Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
         ...
         Section header string table index: 1
       $ readelf -S ./temp.o
       There are 10 section headers, starting at offset 0x288:
      
       Section Headers:
         [Nr] Name              Type             Address           Offset
              Size              EntSize          Flags  Link  Info  Align
         [ 0]                   NULL             0000000000000000  00000000
              0000000000000000  0000000000000000           0     0     0
         [ 1] .strtab           STRTAB           0000000000000000  00000230
              0000000000000051  0000000000000000           0     0     1
              ...
       $ readelf -p .strtab ./temp.o
      
       String dump of section '.strtab':
         [     1]  .text
         [     7]  .comment
         [    10]  .bss
         [    15]  .note.GNU-stack
         [    25]  .rela.eh_frame
         [    34]  func
         [    39]  .strtab
         [    41]  .symtab
         [    49]  .data
         [    4f]  -
      
       $ readelf -p .shstrtab ./temp.o
       readelf: Warning: Section '.shstrtab' was not dumped because it does not exist!
      
      Where, 'section header string table index' points to '.strtab', and
      symbol names are also stored there.
      
      However, in case of gcc:
      
       $ echo 'int func() {return 0;}' | gcc -x c -o temp.o -c -
       $ readelf -p .shstrtab ./temp.o
      
       String dump of section '.shstrtab':
         [     1]  .symtab
         [     9]  .strtab
         [    11]  .shstrtab
         [    1b]  .text
         [    21]  .data
         [    27]  .bss
         [    2c]  .comment
         [    35]  .note.GNU-stack
         [    45]  .rela.eh_frame
       $ readelf -p .strtab ./temp.o
      
       String dump of section '.strtab':
         [     1]  func
      
      They are separated sections.
      
      Although original code doesn't cause error, we'd better use canonical
      method for fetching symbol names to avoid potential behavior changing.
      This patch learns from readelf's code, fetches string from sh_link
      of .symbol section.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Reported-and-Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1449541544-67621-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      77ba9a5b
    • W
      tools lib bpf: Check return value of strdup when reading map names · 973170e6
      Wang Nan 提交于
      Commit 561bbcca ("tools lib bpf:
      Extract and collect map names from BPF object file") forgets checking
      return value of strdup(). This patch fixes it. It also checks names
      pointer before strcmp() for safety.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Fixes: 561bbcca ("tools lib bpf: Extract and collect map names from BPF object file")
      Link: http://lkml.kernel.org/r/1449541544-67621-2-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      973170e6
  4. 28 11月, 2015 2 次提交
  5. 19 11月, 2015 1 次提交
    • W
      bpf tools: Load a program with different instances using preprocessor · b580563e
      Wang Nan 提交于
      This patch is a preparation for BPF prologue support which allows
      generating a series of BPF bytecode for fetching kernel data before
      calling program code. With the newly introduced multiple instances
      support, perf is able to create different prologues for different kprobe
      points.
      
      Before this patch, a bpf_program can be loaded into kernel only once,
      and get the only resulting fd. What this patch does is to allow creating
      and loading different variants of one bpf_program, then fetching their
      fds.
      
      Here we describe the basic idea in this patch. The detailed description
      of the newly introduced APIs can be found in comments in the patch body.
      
      The key of this patch is the new mechanism in bpf_program__load().
      Instead of loading BPF program into kernel directly, it calls a
      'pre-processor' to generate program instances which would be finally
      loaded into the kernel based on the original code. To enable the
      generation of multiple instances, libbpf passes an index to the
      pre-processor so it know which instance is being loaded.
      
      Pre-processor should be called from libbpf's user (perf) using
      bpf_program__set_prep(). The number of instances and the relationship
      between indices and the target instance should be clear when calling
      bpf_program__set_prep().
      
      To retrieve a fd for a specific instance of a program,
      bpf_program__nth_fd() is introduced. It returns the resulting fd
      according to index.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1447675815-166222-8-git-send-email-wangnan0@huawei.comSigned-off-by: NWang Nan <wangnan0@huawei.com>
      [ Enclosed multi-line if/else blocks with {}, (*func_ptr)() -> func_ptr() ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b580563e
  6. 07 11月, 2015 2 次提交
    • W
      bpf tools: Add new API bpf_object__get_kversion() · 45825d8a
      Wang Nan 提交于
      bpf_object__get_kversion() can be used to fetch value of object's
      'version' section. Following patch will use it for error reporting.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1446817783-86722-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      45825d8a
    • W
      bpf tools: Improve libbpf error reporting · 6371ca3b
      Wang Nan 提交于
      In this patch, a series of libbpf specific error numbers and
      libbpf_strerror() are introduced to help reporting errors.
      
      Functions are updated to pass correct the error number through the
      CHECK_ERR() macro.
      
      All users of bpf_object__open{_buffer}() and bpf_program__title() in
      perf are modified accordingly. In addition, due to the error codes
      changing, bpf__strerror_load() is also modified to use them.
      
      bpf__strerror_head() is also changed accordingly so it can parse libbpf
      errors. bpf_loader_strerror() is introduced for that purpose, and will
      be improved by the following patch.
      
      load_program() is improved not to dump log buffer if it is empty. log
      buffer is also used to deduce whether the error was caused by an invalid
      program or other problem.
      
      v1 -> v2:
      
       - Using macro for error code.
      
       - Fetch error message based on array index, eliminate for-loop.
      
       - Use log buffer to detect the reason of failure. 3 new error code
         are introduced to replace LIBBPF_ERRNO__LOAD.
      
      In v1:
      
        # perf record -e ./test_ill_program.o ls
        event syntax error: './test_ill_program.o'
                             \___ Failed to load program: Validate your program and check 'license'/'version' sections in your object
        SKIP
      
        # perf record -e ./test_kversion_nomatch_program.o ls
        event syntax error: './test_kversion_nomatch_program.o'
                             \___ Failed to load program: Validate your program and check 'license'/'version' sections in your object
        SKIP
      
        # perf record -e ./test_big_program.o ls
        event syntax error: './test_big_program.o'
                             \___ Failed to load program: Validate your program and check 'license'/'version' sections in your object
        SKIP
      
        In v2:
      
        # perf record -e ./test_ill_program.o ls
        event syntax error: './test_ill_program.o'
                             \___ Kernel verifier blocks program loading
        SKIP
      
        # perf record -e ./test_kversion_nomatch_program.o
        event syntax error: './test_kversion_nomatch_program.o'
                             \___ Incorrect kernel version
        SKIP
        (Will be further improved by following patches)
      
        # perf record -e ./test_big_program.o
        event syntax error: './test_big_program.o'
                             \___ Program too big
        SKIP
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1446817783-86722-2-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6371ca3b
  7. 03 11月, 2015 1 次提交
  8. 01 9月, 2015 1 次提交
    • W
      bpf tools: New API to get name from a BPF object · acf860ae
      Wang Nan 提交于
      Before this patch there's no way to connect a loaded bpf object
      to its source file. However, during applying perf's '--filter' to BPF
      object, without this connection makes things harder, because perf loads
      all programs together, but '--filter' setting is for each object.
      
      The API of bpf_object__open_buffer() is changed to allow passing a name.
      Fortunately, at this time there's only one user of it (perf test LLVM),
      so we change it together.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Alexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1440742821-44548-2-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      acf860ae
  9. 07 8月, 2015 17 次提交
    • W
      bpf tools: Link all bpf objects onto a list · 9a208eff
      Wang Nan 提交于
      To allow enumeration of all bpf_objects, keep them in a list (hidden to
      caller). bpf_object__for_each_safe() is introduced to do this iteration.
      It is safe even user close the object during iteration.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-23-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9a208eff
    • W
      bpf tools: Introduce accessors for struct bpf_program · aa9b1ac3
      Wang Nan 提交于
      This patch introduces accessors for user of libbpf to retrieve section
      name and fd of a opened/loaded eBPF program. 'struct bpf_prog_handler'
      is used for that purpose. Accessors of programs section name and file
      descriptor are provided. Set/get private data are also impelmented.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Link: http://lkml.kernel.org/r/1435716878-189507-21-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      aa9b1ac3
    • W
      bpf tools: Load eBPF programs in object files into kernel · 55cffde2
      Wang Nan 提交于
      This patch utilizes previous introduced bpf_load_program to load
      programs in the ELF file into kernel. Result is stored in 'fd' field in
      'struct bpf_program'.
      
      During loading, it allocs a log buffer and free it before return.  Note
      that that buffer is not passed to bpf_load_program() if the first
      loading try is successful. Doesn't use a statically allocated log buffer
      to avoid potention multi-thread problem.
      
      Instructions collected during opening is cleared after loading.
      
      load_program() is created for loading a 'struct bpf_insn' array into
      kernel, bpf_program__load() calls it. By this design we have a function
      loads instructions into kernel. It will be used by further patches,
      which creates different instances from a program and load them into
      kernel.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-20-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      55cffde2
    • W
      bpf tools: Relocate eBPF programs · 8a47a6c5
      Wang Nan 提交于
      If an eBPF program accesses a map, LLVM generates a load instruction
      which loads an absolute address into a register, like this:
      
        ld_64   r1, <MCOperand Expr:(mymap)>
        ...
        call    2
      
      That ld_64 instruction will be recorded in relocation section.
      To enable the usage of that map, relocation must be done by replacing
      the immediate value by real map file descriptor so it can be found by
      eBPF map functions.
      
      This patch to the relocation work based on information collected by
      patches:
      
      'bpf tools: Collect symbol table from SHT_SYMTAB section',
      'bpf tools: Collect relocation sections from SHT_REL sections'
      and
      'bpf tools: Record map accessing instructions for each program'.
      
      For each instruction which needs relocation, it inject corresponding
      file descriptor to imm field. As a part of protocol, src_reg is set to
      BPF_PSEUDO_MAP_FD to notify kernel this is a map loading instruction.
      
      This is the final part of map relocation patch. The principle of map
      relocation is described in commit message of 'bpf tools: Collect symbol
      table from SHT_SYMTAB section'.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-18-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8a47a6c5
    • W
      bpf tools: Create eBPF maps defined in an object file · 52d3352e
      Wang Nan 提交于
      This patch creates maps based on 'map' section in object file using
      bpf_create_map(), and stores the fds into an array in 'struct
      bpf_object'.
      
      Previous patches parse ELF object file and collects required data, but
      doesn't play with the kernel. They belong to the 'opening' phase. This
      patch is the first patch in 'loading' phase. The 'loaded' field is
      introduced in 'struct bpf_object' to avoid loading an object twice,
      because the loading phase clears resources collected during the opening
      which becomes useless after loading. In this patch, maps_buf is cleared.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-17-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      52d3352e
    • W
      bpf tools: Record map accessing instructions for each program · 34090915
      Wang Nan 提交于
      This patch records the indices of instructions which are needed to be
      relocated. That information is saved in the 'reloc_desc' field in
      'struct bpf_program'. In the loading phase (this patch takes effect in
      the opening phase), the collected instructions will be replaced by map
      loading instructions.
      
      Since we are going to close the ELF file and clear all data at the end
      of the 'opening' phase, the ELF information will no longer be valid in
      the 'loading' phase. We have to locate the instructions before maps are
      loaded, instead of directly modifying the instruction.
      
      'struct bpf_map_def' is introduced in this patch to let us know how many
      maps are defined in the object.
      
      This is the third part of map relocation. The principle of map relocation
      is described in commit message of 'bpf tools: Collect symbol table from
      SHT_SYMTAB section'.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-15-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      34090915
    • W
      bpf tools: Collect relocation sections from SHT_REL sections · b62f06e8
      Wang Nan 提交于
      This patch collects relocation sections into 'struct object'.  Such
      sections are used for connecting maps to bpf programs. 'reloc' field in
      'struct bpf_object' is introduced for storing such information.
      
      This patch simply store the data into 'reloc' field. Following patch
      will parse them to know the exact instructions which are needed to be
      relocated.
      
      Note that the collected data will be invalid after ELF object file is
      closed.
      
      This is the second patch related to map relocation. The first one is
      'bpf tools: Collect symbol table from SHT_SYMTAB section'. The
      principle of map relocation is described in its commit message.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-14-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b62f06e8
    • W
      bpf tools: Collect eBPF programs from their own sections · a5b8bd47
      Wang Nan 提交于
      This patch collects all programs in an object file into an array of
      'struct bpf_program' for further processing. That structure is for
      representing each eBPF program. 'bpf_prog' should be a better name, but
      it has been used by linux/filter.h. Although it is a kernel space name,
      I still prefer to call it 'bpf_program' to prevent possible confusion.
      
      bpf_object__add_program() creates a new 'struct bpf_program' object.
      It first init a variable in stack using bpf_program__init(), then if
      success, enlarges obj->programs array and copy the new object in.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-13-git-send-email-wangnan0@huawei.com
      [ Made bpf_object__add_program() propagate the error (-EINVAL or -ENOMEM) ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a5b8bd47
    • W
      bpf tools: Collect symbol table from SHT_SYMTAB section · bec7d68c
      Wang Nan 提交于
      This patch collects symbols section. This section is useful when linking
      BPF maps.
      
      What 'bpf_map_xxx()' functions actually require are map's file
      descriptors (and the internal verifier converts fds into pointers to
      'struct bpf_map'), which we don't know when compiling. Therefore, we
      should make compiler generate a 'ldr_64 r1, <imm>' instruction, and
      fill the 'imm' field with the actual file descriptor when loading in
      libbpf.
      
      BPF programs should be written in this way:
      
       struct bpf_map_def SEC("maps") my_map = {
          .type = BPF_MAP_TYPE_HASH,
          .key_size = sizeof(unsigned long),
          .value_size = sizeof(unsigned long),
          .max_entries = 1000000,
       };
      
       SEC("my_func=sys_write")
       int my_func(void *ctx)
       {
           ...
           bpf_map_update_elem(&my_map, &key, &value, BPF_ANY);
           ...
       }
      
      Compiler should convert '&my_map' into a 'ldr_64, r1, <imm>'
      instruction, where imm should be the address of 'my_map'. According to
      the address, libbpf knows which map it actually referenced, and then
      fills the imm field with the 'fd' of that map created by it.
      
      However, since we never really 'link' the object file, the imm field is
      only a record in relocation section. Therefore libbpf should do the
      relocation:
      
       1. In relocation section (type == SHT_REL), positions of each such
          'ldr_64' instruction are recorded with a reference of an entry in
          symbol table (SHT_SYMTAB);
      
       2. From records in symbol table we can find the indics of map
          variables.
      
      Libbpf first record SHT_SYMTAB and positions of each instruction which
      required bu such operation. Then create file descriptor. Finally, after
      map creation complete, replace the imm field.
      
      This is the first patch of BPF map related stuff. It records SHT_SYMTAB
      into object's efile field for further use.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-12-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bec7d68c
    • W
      bpf tools: Collect map definitions from 'maps' section · 0b3d1efa
      Wang Nan 提交于
      If maps are used by eBPF programs, corresponding object file(s) should
      contain a section named 'map'. Which contains map definitions. This
      patch copies the data of the whole section. Map data parsing should be
      acted just before map loading.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-11-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0b3d1efa
    • W
      bpf tools: Collect version and license from ELF sections · cb1e5e96
      Wang Nan 提交于
      Expand bpf_obj_elf_collect() to collect license and kernel version
      information in eBPF object file. eBPF object file should have a section
      named 'license', which contains a string. It should also have a section
      named 'version', contains a u32 LINUX_VERSION_CODE.
      
      bpf_obj_validate() is introduced to validate object file after loaded.
      Currently it only check existence of 'version' section.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-10-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cb1e5e96
    • W
      bpf tools: Iterate over ELF sections to collect information · 29603665
      Wang Nan 提交于
      bpf_obj_elf_collect() is introduced to iterate over each elf sections to
      collection information in eBPF object files. This function will futher
      enhanced to collect license, kernel version, programs, configs and map
      information.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-9-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      29603665
    • W
      bpf tools: Check endianness and make libbpf fail early · cc4228d5
      Wang Nan 提交于
      Check endianness according to EHDR. Code is taken from
      tools/perf/util/symbol-elf.c.
      
      Libbpf doesn't magically convert missmatched endianness. Even if we swap
      eBPF instructions to correct byte order, we are unable to deal with
      endianness in code logical generated by LLVM.
      
      Therefore, libbpf should simply reject missmatched ELF object, and let
      LLVM to create good code.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-8-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc4228d5
    • W
      bpf tools: Read eBPF object from buffer · 6c956392
      Wang Nan 提交于
      To support dynamic compiling, this patch allows caller to pass a
      in-memory buffer to libbpf by bpf_object__open_buffer(). libbpf calls
      elf_memory() to open it as ELF object file.
      
      Because __bpf_object__open() collects all required data and won't need
      that buffer anymore, libbpf uses that buffer directly instead of clone a
      new buffer. Caller of libbpf can free that buffer or use it do other
      things after bpf_object__open_buffer() return.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-7-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6c956392
    • W
      bpf tools: Open eBPF object file and do basic validation · 1a5e3fb1
      Wang Nan 提交于
      This patch defines basic interface of libbpf. 'struct bpf_object' will
      be the handler of each object file. Its internal structure is hide to
      user. eBPF object files are compiled by LLVM as ELF format. In this
      patch, libelf is used to open those files, read EHDR and do basic
      validation according to e_type and e_machine.
      
      All elf related staffs are grouped together and reside in efile field of
      'struct bpf_object'. bpf_object__elf_finish() is introduced to clear it.
      
      After all eBPF programs in an object file are loaded, related ELF
      information is useless. Close the object file and free those memory.
      
      The zfree() and zclose() functions are introduced to ensure setting NULL
      pointers and negative file descriptors after resources are released.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-6-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1a5e3fb1
    • W
      bpf tools: Allow caller to set printing function · b3f59d66
      Wang Nan 提交于
      By libbpf_set_print(), users of libbpf are allowed to register he/she
      own debug, info and warning printing functions. Libbpf will use those
      functions to print messages. If not provided, default info and warning
      printing functions are fprintf(stderr, ...); default debug printing
      is NULL.
      
      This API is designed to be used by perf, enables it to register its own
      logging functions to make all logs uniform, instead of separated
      logging level control.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-5-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b3f59d66
    • W
      bpf tools: Introduce 'bpf' library and add bpf feature check · 1b76c13e
      Wang Nan 提交于
      This is the first patch of libbpf. The goal of libbpf is to create a
      standard way for accessing eBPF object files. This patch creates
      'Makefile' and 'Build' for it, allows 'make' to build libbpf.a and
      libbpf.so, 'make install' to put them into proper directories.
      Most part of Makefile is borrowed from traceevent.
      
      Before building, it checks the existence of libelf in Makefile, and deny
      to build if not found. Instead of throwing an error if libelf not found,
      the error raises in a phony target "elfdep". This design is to ensure
      'make clean' still workable even if libelf is not found.
      
      Because libbpf requires 'kern_version' field set for 'union bpf_attr'
      (bpfdep" is used for that dependency), Kernel BPF API is also checked
      by intruducing a new feature check 'bpf' into tools/build/feature,
      which checks the existence and version of linux/bpf.h. When building
      libbpf, it searches that file from include/uapi/linux in kernel source
      tree (controlled by FEATURE_CHECK_CFLAGS-bpf). Since it searches kernel
      source tree it reside, installing of newest kernel headers is not
      required, except we are trying to port these files to an old kernel.
      
      To avoid checking that file when perf building, the newly introduced
      'bpf' feature check doesn't added into FEATURE_TESTS and
      FEATURE_DISPLAY by default in tools/build/Makefile.feature, but added
      into libbpf's specific.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Bcc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-4-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1b76c13e