1. 23 2月, 2016 1 次提交
  2. 17 2月, 2016 3 次提交
  3. 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
  4. 12 1月, 2016 3 次提交
  5. 11 1月, 2016 2 次提交
  6. 08 1月, 2016 3 次提交
  7. 07 1月, 2016 2 次提交
  8. 18 12月, 2015 2 次提交
  9. 17 12月, 2015 1 次提交
  10. 12 12月, 2015 1 次提交
  11. 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
  12. 28 11月, 2015 2 次提交
  13. 27 11月, 2015 1 次提交
  14. 26 11月, 2015 1 次提交
  15. 24 11月, 2015 1 次提交
  16. 19 11月, 2015 3 次提交
  17. 07 11月, 2015 5 次提交
    • S
      tools/liblockdep: explicitly declare lockdep API we call from liblockdep · 2b62c2db
      Sasha Levin 提交于
      It seems that newer gcc complains about lack of explicit declaration for some
      of the API we use, add it in.
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      2b62c2db
    • S
      tools/liblockdep: add userspace versions of WRITE_ONCE and RCU_INIT_POINTER · e308e942
      Sasha Levin 提交于
      These were added to the kernel code in cee34d88 ("lockdep: Fix a race between
      /proc/lock_stat and module unload"). There's nothing special we need to do
      about them in userspace.
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      e308e942
    • S
      tools/liblockdep: remove task argument from debug_check_no_locks_held · 1393ba5c
      Sasha Levin 提交于
      The tas argument was removed from the kernel code in 1b1d2fb4 ("lockdep:
      remove task argument from debug_check_no_locks_held"). Remove it in loblockdep
      too.
      Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
      1393ba5c
    • 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
  18. 05 11月, 2015 1 次提交
  19. 03 11月, 2015 1 次提交
  20. 23 10月, 2015 1 次提交
  21. 21 10月, 2015 1 次提交
  22. 06 10月, 2015 1 次提交
  23. 01 10月, 2015 1 次提交