1. 28 3月, 2017 1 次提交
    • T
      perf buildid: Do not update SDT cache with null filename · 2ccc2202
      Tommi Rantala 提交于
      Valgrind was complaining:
      
        ==2633== Syscall param open(filename) points to unaddressable byte(s)
        ==2633==    at 0x5281CC0: __open_nocancel (syscall-template.S:84)
        ==2633==    by 0x537D38: open (fcntl2.h:53)
        ==2633==    by 0x537D38: get_sdt_note_list (symbol-elf.c:2017)
        ==2633==    by 0x5396FD: probe_cache__scan_sdt (probe-file.c:700)
        ==2633==    by 0x49EA2C: build_id_cache__add_sdt_cache (build-id.c:625)
        ==2633==    by 0x49EA2C: build_id_cache__add_s (build-id.c:697)
        ==2633==    by 0x49EE72: build_id_cache__add_b (build-id.c:717)
        ==2633==    by 0x49EE72: dso__cache_build_id (build-id.c:782)
        ==2633==    by 0x49F190: __dsos__cache_build_ids (build-id.c:793)
        ==2633==    by 0x49F190: machine__cache_build_ids (build-id.c:801)
        ==2633==    by 0x49F190: perf_session__cache_build_ids (build-id.c:815)
        ==2633==    by 0x4CD4F2: write_build_id (header.c:165)
        ==2633==    by 0x4D26F7: do_write_feat (header.c:2296)
        ==2633==    by 0x4D26F7: perf_header__adds_write (header.c:2335)
        ==2633==    by 0x4D26F7: perf_session__write_header (header.c:2414)
        ==2633==    by 0x43B324: __cmd_record (builtin-record.c:1154)
        ==2633==    by 0x43B324: cmd_record (builtin-record.c:1839)
        ==2633==    by 0x455A07: __cmd_record (builtin-kmem.c:1868)
        ==2633==    by 0x455A07: cmd_kmem (builtin-kmem.c:1944)
        ==2633==    by 0x497150: run_builtin (perf.c:359)
        ==2633==    by 0x428CE0: handle_internal_command (perf.c:421)
        ==2633==    by 0x428CE0: run_argv (perf.c:467)
        ==2633==    by 0x428CE0: main (perf.c:614)
        ==2633==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
      Signed-off-by: NTommi Rantala <tommi.t.rantala@nokia.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tommi Rantala <tommi.t.rantala@nokia.com>
      Link: http://lkml.kernel.org/r/20170322130624.21881-2-tommi.t.rantala@nokia.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2ccc2202
  2. 29 9月, 2016 1 次提交
  3. 14 7月, 2016 2 次提交
    • M
      perf probe: Support @BUILDID or @file suffix for SDT events · a598180a
      Masami Hiramatsu 提交于
      Support @BUILDID or @file suffix for SDT events. This allows perf to add
      probes on SDTs/pre-cached events on given FILE or the file which has
      given BUILDID (also, this complements BUILDID.)
      
      For example, both gcc and libstdc++ has same SDTs as below.  If you
      would like to add a probe on sdt_libstdcxx:catch on gcc, you can do as
      below.
      
        ----
        # perf list sdt | tail -n 6
          sdt_libstdcxx:catch@/usr/bin/gcc(0cc207fc4b27)     [SDT event]
          sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
          sdt_libstdcxx:rethrow@/usr/bin/gcc(0cc207fc4b27)   [SDT event]
          sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
          sdt_libstdcxx:throw@/usr/bin/gcc(0cc207fc4b27)     [SDT event]
          sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.20(91c7a88fdf49)
        # perf probe -a %sdt_libstdcxx:catch@0cc
        Added new event:
          sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)
      
        You can now use it in all perf tools, such as:
      
        	perf record -e sdt_libstdcxx:catch -aR sleep 1
        ----
      
      Committer note:
      
      Doing the full sequence of steps to get the results above:
      
      With a clean build-id cache:
      
        [root@jouet ~]# rm -rf ~/.debug/
        [root@jouet ~]# perf list sdt
      
        List of pre-defined events (to be used in -e):
      
        [root@jouet ~]#
      
      No events whatsoever, then, we can add all events in gcc to the build-id
      cache, doing a --add + --dry-run:
      
        [root@jouet ~]# perf probe --dry-run --cache -x /usr/bin/gcc --add %sdt_libstdcxx:\*
        Added new events:
          sdt_libstdcxx:throw  (on %* in /usr/bin/gcc)
          sdt_libstdcxx:rethrow (on %* in /usr/bin/gcc)
          sdt_libstdcxx:catch  (on %* in /usr/bin/gcc)
      
        You can now use it in all perf tools, such as:
      
      	perf record -e sdt_libstdcxx:catch -aR sleep 1
      
        [root@jouet ~]#
      
      It really didn't add any events, it just cached them:
      
        [root@jouet ~]# perf probe -l
        [root@jouet ~]#
      
      We can see that it was cached as:
      
        [root@jouet ~]# ls -la ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/
        total 976
        drwxr-xr-x. 2 root root   4096 Jul 13 21:47 .
        drwxr-xr-x. 3 root root   4096 Jul 13 21:47 ..
        -rwxr-xr-x. 4 root root 985912 Jun 22 18:52 elf
        -rw-r--r--. 1 root root    303 Jul 13 21:47 probes
        [root@jouet ~]# file ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/elf
        /root/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/elf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2, stripped
        [root@jouet ~]# cat ~/.debug/usr/bin/gcc/9a0730e2bcc6d2a2003d21ac46807e8ee6bcb7c2/probes
        %sdt_libstdcxx:throw=throw
        p:sdt_libstdcxx/throw /usr/bin/gcc:0x71ffd
        %sdt_libstdcxx:rethrow=rethrow
        p:sdt_libstdcxx/rethrow /usr/bin/gcc:0x720b8
        %sdt_libstdcxx:catch=catch
        p:sdt_libstdcxx/catch /usr/bin/gcc:0x7307f
        %sdt_libgcc:unwind=unwind
        p:sdt_libgcc/unwind /usr/bin/gcc:0x7eec0
        #sdt_libstdcxx:*=%*
        [root@jouet ~]#
      
      Ok, now we can use 'perf probe' to refer to those cached entries as:
      
        Humm, nope, doing as above we end up with:
      
        [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch
        Semantic error :* is bad for event name -it must follow C symbol-naming rule.
          Error: Failed to add events.
        [root@jouet ~]#
      
      But it worked at some point, lets try not using --dry-run:
      
      Resetting everything:
      
        # rm -rf ~/.debug/
        # perf probe -d *:*
        # perf probe -l
        # perf list sdt
      
          List of pre-defined events (to be used in -e):
      
        #
      
      Ok, now it cached everything, even things we haven't asked it to
      (sdt_libgcc:unwind):
      
        [root@jouet ~]# perf probe -x /usr/bin/gcc --add %sdt_libstdcxx:\*
        Added new events:
          sdt_libstdcxx:throw  (on %* in /usr/bin/gcc)
          sdt_libstdcxx:rethrow (on %* in /usr/bin/gcc)
          sdt_libstdcxx:catch  (on %* in /usr/bin/gcc)
      
        You can now use it in all perf tools, such as:
      
      	perf record -e sdt_libstdcxx:catch -aR sleep 1
      
        [root@jouet ~]# perf list sdt
      
        List of pre-defined events (to be used in -e):
      
          sdt_libgcc:unwind                                  [SDT event]
          sdt_libstdcxx:catch                                [SDT event]
          sdt_libstdcxx:rethrow                              [SDT event]
          sdt_libstdcxx:throw                                [SDT event]
        [root@jouet ~]#
      
      And we have the events in place:
      
        [root@jouet ~]# perf probe -l
          sdt_libstdcxx:catch  (on execute_cfa_program+1551@../../../libgcc/unwind-dw2.c in /usr/bin/gcc)
          sdt_libstdcxx:rethrow (on d_print_subexpr+280@libsupc++/cp-demangle.c in /usr/bin/gcc)
          sdt_libstdcxx:throw  (on d_print_subexpr+93@libsupc++/cp-demangle.c in /usr/bin/gcc)
        [root@jouet ~]#
      
      And trying to use them at least has 'perf trace --event sdt*:*' working.
      
      Then, if we try to add the ones in libstdc++:
      
        [root@jouet ~]# perf probe -x /usr/lib64/libstdc++.so.6 -a %sdt_libstdcxx:\*
        Error: event "catch" already exists.
         Hint: Remove existing event by 'perf probe -d'
               or force duplicates by 'perf probe -f'
               or set 'force=yes' in BPF source.
          Error: Failed to add events.
        [root@jouet ~]#
      
      Doesn't work, dups, but at least this served to, unbeknownst to the user, add
      the SDT probes in /usr/lib64/libstdc++.so.6!
      
        [root@jouet ~]# perf list sdt
      
        List of pre-defined events (to be used in -e):
      
          sdt_libgcc:unwind                                  [SDT event]
          sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
          sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
          sdt_libstdcxx:rethrow@/usr/bin/gcc(9a0730e2bcc6)   [SDT event]
          sdt_libstdcxx:rethrow@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
          sdt_libstdcxx:throw@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
          sdt_libstdcxx:throw@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
        [root@jouet ~]#
      
      Now we should be able to get to the original cset comment, if we remove all
      SDTs events in place, not from the cache, from the kernel, where it was set up as:
      
        [root@jouet ~]# ls -la /sys/kernel/debug/tracing/events/sdt_libstdcxx/
        total 0
        drwxr-xr-x.  5 root root 0 Jul 13 22:00 .
        drwxr-xr-x. 80 root root 0 Jul 13 21:56 ..
        drwxr-xr-x.  2 root root 0 Jul 13 22:00 catch
        -rw-r--r--.  1 root root 0 Jul 13 22:00 enable
        -rw-r--r--.  1 root root 0 Jul 13 22:00 filter
        drwxr-xr-x.  2 root root 0 Jul 13 22:00 rethrow
        drwxr-xr-x.  2 root root 0 Jul 13 22:00 throw
        [root@jouet ~]#
      
        [root@jouet ~]# head -2 /sys/kernel/debug/tracing/events/sdt_libstdcxx/throw/format
        name: throw
        ID: 2059
        [root@jouet ~]#
      
      Now to remove it:
      
        [root@jouet ~]# perf probe -d sdt_libstdc*:*
        Removed event: sdt_libstdcxx:catch
        Removed event: sdt_libstdcxx:rethrow
        Removed event: sdt_libstdcxx:throw
        [root@jouet ~]#
      
      Which caused:
      
        [root@jouet ~]# ls -la /sys/kernel/debug/tracing/events/sdt_libstdcxx/
        ls: cannot access '/sys/kernel/debug/tracing/events/sdt_libstdcxx/': No such file or directory
        [root@jouet ~]#
      
      Ok, now we can do:
      
        [root@jouet ~]# perf list sdt_libstdcxx:catch
      
        List of pre-defined events (to be used in -e):
      
          sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
          sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
        [root@jouet ~]#
      
      So, these are not really 'pre-defined events', i.e. we can't use them with
      'perf record --event':
      
        [root@jouet ~]# perf record --event sdt_libstdcxx:catch*
        event syntax error: 'sdt_libstdcxx:catch*'
                             \___ unknown tracepoint
      
        Error:	File /sys/kernel/debug/tracing/events/sdt_libstdcxx/catch* not found.
        Hint:	Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
      <SNIP>
        [root@jouet ~]#
      
      To have it really pre-defined we must use perf probe to get its definition from
      the cache and set it up in the kernel, creating the tracepoint to _then_ use it
      with 'perf record --event':
      
        [root@jouet ~]# perf probe -a sdt_libstdcxx:catch
        Semantic error :There is non-digit char in line number.
        <SNIP>
      
      Oops, there is another gotcha here, we need that pesky '%' character:
      
        [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch
        Added new events:
          sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)
          sdt_libstdcxx:catch_1 (on %catch in /usr/lib64/libstdc++.so.6.0.22)
      
        You can now use it in all perf tools, such as:
      
      	perf record -e sdt_libstdcxx:catch_1 -aR sleep 1
      
        [root@jouet ~]#
      
      But then we added _two_ events, one with the name we expected, the other one
      with a _ added, when doing the analysis we need to pay attention to who maps to
      who.
      
      And here is where we get to the point of this patch, which is to be able to
      disambiguate those definitions for 'catch' in the build-id cache, but first we need
      remove those events we just added:
      
      [root@jouet ~]# perf probe -d %sdt_libstdcxx:catch
      
      Oops, that didn't remove anything, we need to _remove_ that % char in this case:
      
        [root@jouet ~]# perf probe -d sdt_libstdcxx:catch
        Removed event: sdt_libstdcxx:catch
      
      And we need to remove the other event added, i.e. I forgot to add a * at the end:
      
        [root@jouet ~]# perf probe -d sdt_libstdcxx:catch*
        Removed event: sdt_libstdcxx:catch_1
        [root@jouet ~]#
      
      Ok, disambiguating it using what is in this patch:
      
        [root@jouet ~]# perf list sdt_libstdcxx:catch
      
        List of pre-defined events (to be used in -e):
      
          sdt_libstdcxx:catch@/usr/bin/gcc(9a0730e2bcc6)     [SDT event]
          sdt_libstdcxx:catch@/usr/lib64/libstdc++.so.6.0.22(ef2b7066559a) [SDT event]
        [root@jouet ~]#
        [root@jouet ~]# perf probe -a %sdt_libstdcxx:catch@9a07
        Added new event:
          sdt_libstdcxx:catch  (on %catch in /usr/bin/gcc)
      
        You can now use it in all perf tools, such as:
      
      	perf record -e sdt_libstdcxx:catch -aR sleep 1
      
        [root@jouet ~]# perf probe -l
          sdt_libstdcxx:catch  (on execute_cfa_program+1551@../../../libgcc/unwind-dw2.c in /usr/bin/gcc)
        [root@jouet ~]#
      
      Yeah, it works! But we need to try and simplify this :-)
      
      Update: Some aspects of this simplification take place in the following
              patches.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/146831793746.17065.13065062753978236612.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a598180a
    • M
      perf probe: Make --list show only available cached events · c3492a3a
      Masami Hiramatsu 提交于
      Make "perf probe --cache --list" show only available cached events by
      checking build-id validity.
      
      E.g. without this patch:
        ----
        $ ./perf probe --cache --add oldevent=cmd_probe
        $ make #(to update ./perf)
        $ ./perf probe --cache --add newevent=cmd_probe
        $ ./perf probe --cache --list
        /home/mhiramat/ksrc/linux/tools/perf/perf (061e90539bac69
        probe_perf:newevent=cmd_probe
        /home/mhiramat/ksrc/linux/tools/perf/perf (c2e44d614e33e1
        probe_perf:oldevent=cmd_probe
        ----
      It shows both of old and new events but user can not use old one.
      With this;
        ----
        $ ./perf probe --cache -l
        /home/mhiramat/ksrc/linux/tools/perf/perf (061e90539bac69
        probe_perf:newevent=cmd_probe
        ----
      
      This shows only new events which are on the existing binary.
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/146831789417.17065.17896487479879669610.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c3492a3a
  4. 13 7月, 2016 1 次提交
    • A
      perf tools: Add feature detection for gelf_getnote() · 1c1a3a47
      Arnaldo Carvalho de Melo 提交于
      That is not present on some libelf implementations, such as the one used
      in Alpine Linux: libelf-0.8.13.
      
      This ends up disabling the SDT code, that relies on this function.
      
      One alternative would be to provide an weak fallback implementation or
      the open coded variant used by the buildid sysfs notes reading code.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-82lh22ybedy9b9lych8xj12g@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c1a3a47
  5. 05 7月, 2016 1 次提交
    • M
      perf buildid-cache: Scan and import user SDT events to probe cache · 6430a94e
      Masami Hiramatsu 提交于
      perf buildid-cache --add <binary> scans given binary and add
      the SDT events to probe cache. "sdt_" prefix is appended for
      all SDT providers to avoid event-name clash with other pre-defined
      events. It is possible to use the cached SDT events as other cached
      events, via perf probe --add "sdt_<provider>:<event>=<event>".
      
      e.g.
        ----
        # perf buildid-cache --add /lib/libc-2.17.so
        # perf probe --cache --list | head -n 5
        /usr/lib/libc-2.17.so (a6fb821bdf53660eb2c29f778757aef294d3d392):
        sdt_libc:setjmp=setjmp
        sdt_libc:longjmp=longjmp
        sdt_libc:longjmp_target=longjmp_target
        sdt_libc:memory_heap_new=memory_heap_new
        # perf probe -x /usr/lib/libc-2.17.so \
          -a sdt_libc:memory_heap_new=memory_heap_new
        Added new event:
          sdt_libc:memory_heap_new (on memory_heap_new
         in /usr/lib/libc-2.17.so)
      
        You can now use it in all perf tools, such as:
      
                perf record -e sdt_libc:memory_heap_new -aR sleep 1
      
        # perf probe -l
          sdt_libc:memory_heap_new (on new_heap+183 in /usr/lib/libc-2.17.so)
        ----
      
      Note that SDT event entries in probe-cache file is somewhat different
      from normal cached events. Normal one starts with "#", but SDTs are
      starting with "%".
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/146736025058.27797.13043265488541434502.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6430a94e
  6. 01 7月, 2016 1 次提交
  7. 14 6月, 2016 1 次提交
  8. 07 6月, 2016 1 次提交
    • W
      perf tools: Fix crash in build_id_cache__kallsyms_path() · c58c49ac
      Wang Nan 提交于
      build_id_cache__kallsyms_path() accepts a string buffer but also allocs
      a buffer using asnprintf. Unfortunately, the its only user passes it a
      stack-allocated buffer. Freeing it causes crashes like this:
      
        $ perf script
        *** Error in `/home/wangnan/perf': free(): invalid pointer: 0x00007fffffff9630 ***
        ======= Backtrace: =========
        lib64/libc.so.6(+0x6eeef)[0x7ffff5dbaeef]
        lib64/libc.so.6(+0x78cae)[0x7ffff5dc4cae]
        lib64/libc.so.6(+0x79987)[0x7ffff5dc5987]
        /home/w00229757/perf(build_id_cache__kallsyms_path+0x6b)[0x49681b]
        /home/w00229757/perf[0x4bdd40]
        /home/w00229757/perf(dso__load+0xa3a)[0x4c048a]
        /home/w00229757/perf(map__load+0x6f)[0x4d561f]
        /home/w00229757/perf(thread__find_addr_map+0x235)[0x49e935]
        /home/w00229757/perf(machine__resolve+0x7d)[0x49ec6d]
        /home/w00229757/perf[0x4555a8]
        /home/w00229757/perf[0x4d9507]
        /home/w00229757/perf[0x4d9e80]
        /home/w00229757/perf(ordered_events__flush+0x354)[0x4dd444]
        /home/w00229757/perf(perf_session__process_events+0x3d0)[0x4dc140]
        /home/w00229757/perf(cmd_script+0x12b0)[0x4592e0]
        /home/w00229757/perf[0x4911f1]
        /home/w00229757/perf(main+0x68f)[0x4352ef]
        /lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff5d6dbd5]
        /home/w00229757/perf[0x435415]
        ======= Memory map: ========
      
      This patch simplifies build_id_cache__kallsyms_path(), not even
      considering allocating a string buffer, so never frees anything. Its
      caller should manage memory allocation.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Fixes: 01412261 ("perf buildid-cache: Use path/to/bin/buildid/elf instead of path/to/bin/buildid")
      Link: http://lkml.kernel.org/r/1465271678-7392-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c58c49ac
  9. 31 5月, 2016 1 次提交
  10. 17 5月, 2016 1 次提交
    • H
      perf symbols: Store vdso buildid unconditionally · 6ae98ba6
      He Kuang 提交于
      When unwinding callchains on a different machine, vdso info should be
      available so the unwind process won't be interrupted if address falls
      into vdso region. But in most cases, the addresses of sample events are
      not in vdso range, the buildid of a zero hit vdso won't be stored into
      perf.data.
      
      This patch stores vdso buildid regardless of whether the vdso is hit or
      not.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1463042596-61703-3-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6ae98ba6
  11. 12 5月, 2016 1 次提交
  12. 25 4月, 2016 1 次提交
    • A
      perf buildid: Fix off-by-one in write_buildid() · 70a2cba9
      Andrey Ryabinin 提交于
      write_buildid() increments 'name_len' with intention to take into
      account trailing zero byte. However, 'name_len' was already incremented
      in machine__write_buildid_table() before.  So this leads to
      out-of-bounds read in do_write():
      
        $ ./perf record sleep 0
        [ perf record: Woken up 1 times to write data ]
        =================================================================
        ==15899==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000099fc92 at pc 0x7f1aa9c7eab5 bp 0x7fff940f84d0 sp 0x7fff940f7c78
        READ of size 19 at 0x00000099fc92 thread T0
            #0 0x7f1aa9c7eab4  (/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/libasan.so.2+0x44ab4)
            #1 0x649c5b in do_write util/header.c:67
            #2 0x649c5b in write_padded util/header.c:82
            #3 0x57e8bc in write_buildid util/build-id.c:239
            #4 0x57e8bc in machine__write_buildid_table util/build-id.c:278
        ...
      
        0x00000099fc92 is located 0 bytes to the right of global variable '*.LC99' defined in 'util/symbol.c' (0x99fc80) of size 18
          '*.LC99' is ascii string '[kernel.kallsyms]'
        ...
      
        Shadow bytes around the buggy address:
          0x00008012bf80: f9 f9 f9 f9 00 00 00 00 00 00 03 f9 f9 f9 f9 f9
        =>0x00008012bf90: 00 00[02]f9 f9 f9 f9 f9 00 00 00 00 00 05 f9 f9
          0x00008012bfa0: f9 f9 f9 f9 00 03 f9 f9 f9 f9 f9 f9 00 00 00 00
      Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1461053847-5633-1-git-send-email-aryabinin@virtuozzo.com
      [ Remove the off-by one at the origin, to keep len(s) == strlen(s) assumption ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      70a2cba9
  13. 23 3月, 2016 1 次提交
  14. 12 2月, 2016 1 次提交
    • W
      perf symbols: Fix symbols searching for module in buildid-cache · e7ee4047
      Wang Nan 提交于
      Before this patch, if a sample is triggered inside a module not in
      /lib/modules/`uname -r`/, even if the module is in buildid-cache, 'perf
      report' will still be unable to find the correct symbol.  For example:
      
        # rm -rf ~/.debug/
        # perf buildid-cache -a ./mymodule.ko
        # perf probe -m ./mymodule.ko -a get_mymodule_val
        Added new event:
          probe:get_mymodule_val (on get_mymodule_val in mymodule)
      
        You can now use it in all perf tools, such as:
      
       	perf record -e probe:get_mymodule_val -aR sleep 1
      
        # perf record -e probe:get_mymodule_val cat /proc/mymodule
        mymodule:3
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
      
        # perf report --stdio
        [SNIP]
        #
        # Overhead  Command  Shared Object     Symbol
        # ........  .......  ................  ......................
        #
          100.00%  cat      [mymodule]        [k] 0x0000000000000001
      
        # perf report -vvvv --stdio
        dso__load_sym: adjusting symbol: st_value: 0 sh_addr: 0 sh_offset: 0x70
        symbol__new: get_mymodule_val 0x70-0x8a
        [SNIP]
      
      This is caused by dso__load() -> dso__load_sym(). In dso__load(), kmod
      is true only when its file is found in some well know directories. All
      files loaded from buildid-cache are treated as user programs. Following
      dso__load_sym() set map->pgoff incorrectly.
      
      This patch gives kernel modules in buildid-cache a chance to adjust
      value of kmod. After dso__load() get the type of symbols, if it is
      buildid, check the last 3 chars of original filename against '.ko', and
      adjust the value of kmod if the file is a kernel module.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Cody P Schafer <dev@codyps.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jeremie Galarneau <jeremie.galarneau@efficios.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kirill Smelkov <kirr@nexedi.com>
      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: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1454680939-24963-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e7ee4047
  15. 30 1月, 2016 1 次提交
    • W
      perf buildid: Fix cpumode of buildid event · fd786fac
      Wang Nan 提交于
      There is a nasty confusion that, for kernel module, dso->kernel is not
      necessary to be DSO_TYPE_KERNEL or DSO_TYPE_GUEST_KERNEL.  These two
      enums are for vmlinux. See thread [1]. We tried to fix this part but it
      is costy.
      
      Code machine__write_buildid_table() is another unfortunate function fall
      into this trap that, when issuing buildid event for a kernel module,
      cpumode it gives to the event is PERF_RECORD_MISC_USER, not
      PERF_RECORD_MISC_KERNEL.
      
      However, even with this bug, most of the time it doesn't causes real
      problem. I find this issue when trying to use a perf before commit
      3d39ac53 ("perf machine: No need to have two DSOs lists") to parse a
      perf.data generated by newest perf.
      
      [1] https://lkml.org/lkml/2015/9/21/908Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Li Zefan <lizefan@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1454089251-203152-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fd786fac
  16. 07 12月, 2015 1 次提交
    • M
      perf buildid-list: Show running kernel build id fix · 7375e151
      Michael Petlan 提交于
      The --kernel option of perf buildid-list tool should show the running
      kernel buildid.  The functionality has been lost during other changes of
      the related code.
      
      The build_id__sprintf() function should return length of the build-id
      string,  but it was the length of the build-id raw data instead. Due to
      that, some return value checking caused that the final string was not
      printed out.
      
      With this patch the build_id__sprintf() returns the correct value, so
      the --kernel option works again.
      
      Before:
      
      	# perf buildid-list --kernel
      	#
      
      After:
      
      	# perf buildid-list --kernel
      	972c1edab5bdc06cc224af45d510af662a3c6972
      	#
      Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      LPU-Reference: 1448632089.24573.114.camel@redhat.com
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7375e151
  17. 27 11月, 2015 1 次提交
    • M
      perf buildid-list: Show running kernel build id fix · c4e07949
      Michael Petlan 提交于
      The --kernel option of perf buildid-list tool should show the running
      kernel buildid.  The functionality has been lost during other changes of
      the related code.
      
      The build_id__sprintf() function should return length of the build-id
      string,  but it was the length of the build-id raw data instead. Due to
      that, some return value checking caused that the final string was not
      printed out.
      
      With this patch the build_id__sprintf() returns the correct value, so
      the --kernel option works again.
      
      Before:
      
      	# perf buildid-list --kernel
      	#
      
      After:
      
      	# perf buildid-list --kernel
      	972c1edab5bdc06cc224af45d510af662a3c6972
      	#
      Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      LPU-Reference: 1448632089.24573.114.camel@redhat.com
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c4e07949
  18. 13 11月, 2015 1 次提交
  19. 29 8月, 2015 1 次提交
  20. 21 7月, 2015 1 次提交
  21. 20 7月, 2015 1 次提交
  22. 29 5月, 2015 1 次提交
  23. 09 5月, 2015 1 次提交
    • A
      perf machine: Protect the machine->threads with a rwlock · b91fc39f
      Arnaldo Carvalho de Melo 提交于
      In addition to using refcounts for the struct thread lifetime
      management, we need to protect access to machine->threads from
      concurrent access.
      
      That happens in 'perf top', where a thread processes events, inserting
      and deleting entries from that rb_tree while another thread decays
      hist_entries, that end up dropping references and ultimately deleting
      threads from the rb_tree and releasing its resources when no further
      hist_entry (or other data structures, like in 'perf sched') references
      it.
      
      So the rule is the same for refcounts + protected trees in the kernel,
      get the tree lock, find object, bump the refcount, drop the tree lock,
      return, use object, drop the refcount if no more use of it is needed,
      keep it if storing it in some other data structure, drop when releasing
      that data structure.
      
      I.e. pair "t = machine__find(new)_thread()" with a "thread__put(t)", and
      "perf_event__preprocess_sample(&al)" with "addr_location__put(&al)".
      
      The addr_location__put() one is because as we return references to
      several data structures, we may end up adding more reference counting
      for the other data structures and then we'll drop it at
      addr_location__put() time.
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-bs9rt4n0jw3hi9f3zxyy3xln@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b91fc39f
  24. 10 4月, 2015 1 次提交
    • H
      perf buildid-list: Fix segfault when show DSOs with hits · 5e78c69b
      He Kuang 提交于
      commit: f3b623b8 ("perf tools: Reference count struct thread")
      appends every thread->node to dead_threads in machine__remove_thread()
      and list_del_init() this node in thread__put().
      
      perf_event__exit_del_thread() releases thread wihout using
      machine__remove_thread(), and causes a NULL pointer crash when
      list_del_init(&thread->node) is called. Fix this by using
      machine_remove_thread() instead of using thread__put() directly.
      
      This problem can be reproduced as following:
      
        $ perf record ls
        $ perf buildid-list --with-hits
        [ 3874.195070] perf[1018]: segfault at 0 ip 00000000004b0b15 sp
        00007ffc35b44780 error 6 in perf[400000+166000]
        Segmentation fault
      
      After this patch:
        $ perf record ls
        $ perf buildid-list --with-hits
        bc23e7c3281e542650ba4324421d6acf78f4c23e /proc/kcore
        643324cb0e969f30c56d660f167f84a150845511 [vdso]
        0000000000000000000000000000000000000000 /bin/busybox
        ...
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1428658500-6483-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5e78c69b
  25. 21 3月, 2015 1 次提交
    • M
      perf tools: Fix race in build_id_cache__add_s() · 0635b0f7
      Milos Vyletel 提交于
      int build_id_cache__add_s(const char *sbuild_id, const char *debugdir,
                                const char *name, bool is_kallsyms, bool is_vdso)
      {
      ...
              if (access(filename, F_OK)) {
                     ^--------------------------------------------------------- [1]
                      if (is_kallsyms) {
                               if (copyfile("/proc/kallsyms", filename))
                                      goto out_free;
                      } else if (link(realname, filename) && copyfile(name, filename))
                                   ^-----------------------------^------------- [2]
                                                                  \------------ [3]
                              goto out_free;
              }
      ...
      
      When multiple instances of perf record get to [1] at more or less same time and
      run access() one or more may get failure because the file does not exist yet
      (since the first instance did not have chance to link it yet).
      
      At this point the race moves to link() at [2] where first thread to get
      there links file and goes on but second one gets -EEXIST so it runs
      copyfile [3] which truncates the file.
      
      reproducer:
      
      rm -rf /root/.debug
      for cpu in $(awk '/processor/ {print $3}' /proc/cpuinfo); do
      	perf record -a -v -T -F 1000 -C $cpu \
      		-o perf-${cpu}.data sleep 5 2> /dev/null &
      done
      wait
      
      and simply search for empty files by:
      
      find /lib/modules/`uname -r`/kernel/* -size 0
      Signed-off-by: NMilos Vyletel <milos@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1426847846-11112-1-git-send-email-milos@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0635b0f7
  26. 03 3月, 2015 1 次提交
    • A
      perf tools: Reference count struct thread · f3b623b8
      Arnaldo Carvalho de Melo 提交于
      We need to do that to stop accumulating entries in the dead_threads
      linked list, i.e. we were keeping references to threads in struct hists
      that continue to exist even after a thread exited and was removed from
      the machine threads rbtree.
      
      We still keep the dead_threads list, but just for debugging, allowing us
      to iterate at any given point over the threads that still are referenced
      by things like struct hist_entry.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-3ejvfyed0r7ue61dkurzjux4@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f3b623b8
  27. 28 2月, 2015 1 次提交
    • M
      perf buildid-cache: Add --purge FILE to remove all caches of FILE · 8d8c8e4c
      Masami Hiramatsu 提交于
      Add --purge FILE to remove all caches of FILE.
      
      Since the current --remove FILE removes a cache which has
      same build-id of given FILE. Since the command takes a
      FILE path, it can confuse user who tries to remove cache
      about FILE path.
      
        -----
        # ./perf buildid-cache -v --add ./perf
        Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
        # (update the ./perf binary)
        # ./perf buildid-cache -v --remove ./perf
        Removing 305bbd1be68f66eca7e2d78db294653031edfa79 ./perf: FAIL
        ./perf wasn't in the cache
        -----
      Actually, the --remove's FAIL is not shown, it just silently fails.
      
      So, this patch adds --purge FILE action for such usecase.
      
      perf buildid-cache --purge FILE removes all caches which has same FILE
      path.
      
      In other words, it removes all caches including old binaries.
      
        -----
        # ./perf buildid-cache -v --add ./perf
        Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
        # (update the ./perf binary)
        # ./perf buildid-cache -v --purge ./perf
        Removing 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
        -----
      
      BTW, if you want to purge all the caches, remove ~/.debug/* .
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20150227045026.1999.64084.stgit@localhost.localdomain
      [ s/dirname/dir_name/g to fix build on fedora14, where dirname is a global ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8d8c8e4c
  28. 27 2月, 2015 1 次提交
    • M
      perf buildid-cache: Add new buildid cache if update target is not cached · a50d11a1
      Masami Hiramatsu 提交于
      Add new buildid cache if the update target file is not cached.
      
      This can happen when an old binary is replaced by new one after caching
      the old one. In this case, user sees his operation just failed.
      
      But it does not look straight, since user just pass the binary "path",
      not "build-id".
      
        ----
        # ./perf buildid-cache --add ./perf
        (update ./perf to new binary)
        # ./perf buildid-cache --update ./perf
        ./perf wasn't in the cache
        #
        ----
      
      This patch adds given new binary to cache if the new binary is
      not cached. So we'll not see the above error.
      
        ----
        # ./perf buildid-cache --add ./perf
        (update ./perf to new binary)
        # ./perf buildid-cache --update ./perf
        #
        ----
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20150226065440.23912.1494.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a50d11a1
  29. 11 2月, 2015 2 次提交
  30. 09 12月, 2014 1 次提交
  31. 19 11月, 2014 1 次提交
  32. 05 11月, 2014 1 次提交
  33. 29 10月, 2014 1 次提交
  34. 12 5月, 2014 1 次提交
  35. 11 12月, 2013 1 次提交
  36. 23 10月, 2013 1 次提交
  37. 11 9月, 2013 1 次提交
    • S
      perf tools: Add attr->mmap2 support · 5c5e854b
      Stephane Eranian 提交于
      This patch adds support for the new PERF_RECORD_MMAP2 record type
      exposed by the kernel. This is an extended PERF_RECORD_MMAP record.
      
      It adds for each file-backed mapping the device major, minor number and
      the inode number and generation.
      
      This triplet uniquely identifies the source of a file-backed mapping. It
      can be used to detect identical virtual mappings between processes, for
      instance.
      
      The patch will prefer MMAP2 over MMAP.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1377079825-19057-3-git-send-email-eranian@google.com
      [ Cope with 314add6b "Change machine__findnew_thread() to set thread pid",
        fix 'perf test' regression test entry affected,
        use perf_missing_features.mmap2 to fallback to not using .mmap2 in older kernels,
        so that new tools can work with kernels where this feature is not present ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c5e854b
  38. 30 8月, 2013 1 次提交