Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 4月, 2017 3 次提交
  3. 17 3月, 2017 1 次提交
    • D
      perf symbols: Fix symbols__fixup_end heuristic for corner cases · e7ede72a
      由 Daniel Borkmann 提交于 
      The current symbols__fixup_end() heuristic for the last entry in the rb
tree is suboptimal as it leads to not being able to recognize the symbol
in the call graph in a couple of corner cases, for example:

 i) If the symbol has a start address (f.e. exposed via kallsyms)
    that is at a page boundary, then the roundup(curr->start, 4096)
    for the last entry will result in curr->start == curr->end with
    a symbol length of zero.

ii) If the symbol has a start address that is shortly before a page
    boundary, then also here, curr->end - curr->start will just be
    very few bytes, where it's unrealistic that we could perform a
    match against.

Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so
that we can catch such corner cases and have a better chance to find
that specific symbol. It's still just best effort as the real end of the
symbol is unknown to us (and could even be at a larger offset than the
current range), but better than the current situation.

Alexei reported that he recently run into case i) with a JITed eBPF
program (these are all page aligned) as the last symbol which wasn't
properly shown in the call graph (while other eBPF program symbols in
the rb tree were displayed correctly). Since this is a generic issue,
lets try to improve the heuristic a bit.
Reported-and-Tested-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Fixes: 2e538c4a ("perf tools: Improve kernel/modules symbol lookup")
Link: http://lkml.kernel.org/r/bb5c80d27743be6f12afc68405f1956a330e1bc9.1489614365.git.daniel@iogearbox.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e7ede72a
  5. 08 2月, 2017 1 次提交
    • V
      perf symbols: Take into account symfs setting when reading file build ID · 9b200653
      由 Victor Kamensky 提交于 
      After commit 5baecbcd ("perf symbols: we can now read separate
debug-info files based on a build ID") and when --symfs option is used
perf failed to pick up symbols for file with the same name between host
and sysroot specified by --symfs option.  One can see message like this:

  bin/bash with build id 26f0062cb6950d4d1ab0fd9c43eae8b10ca42062 not found, continuing without symbols

It happens because code added by 5baecbcd opens files directly by
dso->long_name without symbol_conf.symfs consideration, which as result
picks one from the host. It reads its build ID and later even code finds
another proper file in directory pointed by --symfs perf ignores it
because build id mismatches.

Fix is to use __symbol__join_symfs to adjust file name according to
--symfs setting. If no --symfs passed the operation would noop and picks
the same host file as before.

Also note in latter tree after 5baecbcd commit additional check for
'!dso->has_build_id' was added, so to observe error condition 'perf
record' should run with --no-buildid, so perf.data itself would not have
build id for target binary in buildid perf section and 'perf report'
will pass '!dso->has_build_id' condition. Or target binary should not
have build id, but the same binary on host has build id, again
'!dso->has_build_id' will pass in this case and incorrect build id could
be read if --symfs is used.
Signed-off-by: NVictor Kamensky <kamensky@cisco.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Chris Phlipot <cphlipot0@gmail.com>
Cc: Dima Kogan <dima@secretsauce.net>
Cc: He Kuang <hekuang@huawei.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Cc: xe-linux-external@cisco.com
Fixes: 5baecbcd ("perf symbols: we can now read separate debug-info files based on a build ID")
Link: http://lkml.kernel.org/r/1486424908-17094-1-git-send-email-kamensky@cisco.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9b200653
  7. 20 12月, 2016 1 次提交
    • K
      perf diff: Do not overwrite valid build id · ed6c166c
      由 Kan Liang 提交于 
      Fixes a perf diff regression issue which was introduced by commit
5baecbcd ("perf symbols: we can now read separate debug-info files
based on a build ID")

The binary name could be same when perf diff different binaries. Build
id is used to distinguish between them.
However, the previous patch assumes the same binary name has same build
id. So it overwrites the build id according to the binary name,
regardless of whether the build id is set or not.

Check the has_build_id in dso__load. If the build id is already set, use
it.

Before the fix:

  $ perf diff 1.perf.data 2.perf.data
  # Event 'cycles'
  #
  # Baseline    Delta  Shared Object     Symbol
  # ........  .......  ................  .............................
  #
    99.83%  -99.80%  tchain_edit       [.] f2
     0.12%  +99.81%  tchain_edit       [.] f3
     0.02%   -0.01%  [ixgbe]           [k] ixgbe_read_reg

  After the fix:
  $ perf diff 1.perf.data 2.perf.data
  # Event 'cycles'
  #
  # Baseline    Delta  Shared Object     Symbol
  # ........  .......  ................  .............................
  #
    99.83%   +0.10%  tchain_edit       [.] f3
     0.12%   -0.08%  tchain_edit       [.] f2
Signed-off-by: NKan Liang <kan.liang@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
CC: Dima Kogan <dima@secretsauce.net>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Fixes: 5baecbcd ("perf symbols: we can now read separate debug-info files based on a build ID")
Link: http://lkml.kernel.org/r/1481642984-13593-1-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ed6c166c
  9. 30 11月, 2016 1 次提交
    • D
      perf script: Add option to stop printing callchain · 64eff7d9
      由 David Ahern 提交于 
      Allow user to specify list of symbols which cause the dump of callchains
to stop at that symbol.

Committer notes:

Testing it:

  # perf record -ag usleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 1.177 MB perf.data (33 samples) ]
  #
  # # Without it:
  #
  # perf script
  swapper   0 [000]  9693.370039:          1 cycles:ppp:
                  2072ad x86_pmu_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  326978 flush_smp_call_function_queue (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  327413 generic_smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  249b37 smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  a04b2c call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  889427 cpuidle_enter (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  2e534a call_cpuidle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  2e5730 cpu_startup_entry (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  9f5167 rest_init (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                 137ffeb start_kernel ([kernel.vmlinux].init.text)
                 137f2ca x86_64_start_reservations ([kernel.vmlinux].init.text)
                 137f419 x86_64_start_kernel ([kernel.vmlinux].init.text)

  swapper   0 [000]  9693.370044:          1 cycles:ppp:
                  20ca1b intel_pmu_handle_irq (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  205b0c perf_event_nmi_handler (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a14a nmi_handle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a6b3 default_do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a83c do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  a03fb1 end_repeat_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  326978 flush_smp_call_function_queue (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  327413 generic_smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  249b37 smp_call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  a04b2c call_function_single_interrupt (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  889427 cpuidle_enter (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  2e534a call_cpuidle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  2e5730 cpu_startup_entry (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  9f5167 rest_init (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                 137ffeb start_kernel ([kernel.vmlinux].init.text)
                 137f2ca x86_64_start_reservations ([kernel.vmlinux].init.text)
  #
  # # Using it to see just what are the calls from the 'remote_function' function:
  #
  # perf script --stop-bt remote_function
  swapper   0 [000]  9693.370039:          1 cycles:ppp:
                  2072ad x86_pmu_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)

  swapper   0 [000]  9693.370044:          1 cycles:ppp:
                  20ca1b intel_pmu_handle_irq (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  205b0c perf_event_nmi_handler (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a14a nmi_handle (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a6b3 default_do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  22a83c do_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  a03fb1 end_repeat_nmi (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a29d7 perf_pmu_enable.part.90 (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a713a ctx_resched (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a76c1 __perf_event_enable (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a0390 event_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
                  3a1cff remote_function (/usr/lib/debug/lib/modules/4.8.8-300.fc25.x86_64/vmlinux)
Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.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 <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1480104021-36275-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      64eff7d9
  11. 25 11月, 2016 1 次提交
    • W
      perf record: Fix segfault when running with suid and kptr_restrict is 1 · 3dbe46c5
      由 Wang Nan 提交于 
      Before this patch perf panics if kptr_restrict is set to 1 and perf is
owned by root with suid set:

  $ whoami
  wangnan
  $ ls -l ./perf
  -rwsr-xr-x 1 root root 19781908 Sep 21 19:29 /home/wangnan/perf
  $ cat /proc/sys/kernel/kptr_restrict
  1
  $ cat /proc/sys/kernel/perf_event_paranoid
  -1
  $ ./perf record -a
  Segmentation fault (core dumped)
  $

The reason is that perf assumes it is allowed to read kptr from
/proc/kallsyms when euid is root, but in fact the kernel doesn't allow
reading kptr when euid and uid do not match with each other:

  $ cp /bin/cat .
  $ sudo chown root:root ./cat
  $ sudo chmod u+s ./cat
  $ cat /proc/kallsyms | grep do_fork
  0000000000000000 T _do_fork          <--- kptr is hidden even euid is root
  $ sudo cat /proc/kallsyms | grep do_fork
  ffffffff81080230 T _do_fork

See lib/vsprintf.c for kernel side code.

This patch fixes this problem by checking both uid and euid.
Signed-off-by: NWang Nan <wangnan0@huawei.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/20161115040617.69788-3-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3dbe46c5
  13. 29 9月, 2016 1 次提交
  15. 05 9月, 2016 2 次提交
  17. 01 9月, 2016 2 次提交
  19. 30 8月, 2016 1 次提交
  21. 28 6月, 2016 1 次提交
    • J
      perf symbols: Use proper dso name for is_regular_file · ed7b630b
      由 Jiri Olsa 提交于 
      Marc reported use of uninitialized memory:

> In commit "40356721 perf symbols: Do not read symbols/data from
> device files" a check to uninitialzied memory was added. This leads to
> the following valgrind output:
>
>  ==24515== Syscall param stat(file_name) points to uninitialised byte(s)
>  ==24515==    at 0x75B26D5: _xstat (in /lib/x86_64-linux-gnu/libc-2.22.so)
>  ==24515==    by 0x4E548D: stat (stat.h:454)
>  ==24515==    by 0x4E548D: is_regular_file (util.c:687)
>  ==24515==    by 0x4A5BEE: dso__load (symbol.c:1435)
>  ==24515==    by 0x4BB1AE: map__load (map.c:289)
>  ==24515==    by 0x4BB1AE: map__find_symbol (map.c:333)
>  ==24515==    by 0x4835B3: thread__find_addr_location (event.c:1300)
>  ==24515==    by 0x4B5342: add_callchain_ip (machine.c:1652)
>  ==24515==    by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
>  ==24515==    by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
>  ==24515==    by 0x441B3E: process_event (builtin-script.c:795)
>  ==24515==    by 0x441B3E: process_sample_event (builtin-script.c:920)
>  ==24515==    by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
>  ==24515==    by 0x4BEE29: machines__deliver_event (session.c:1229)
>  ==24515==    by 0x4BF770: perf_session__deliver_event (session.c:1286)
>  ==24515==    by 0x4BF770: ordered_events__deliver_event (session.c:114)
>  ==24515==    by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
>  ==24515==    by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
>  ==24515==    by 0x4BF44C: perf_session__process_user_event (session.c:1325)
>  ==24515==    by 0x4BF44C: perf_session__process_event (session.c:1451)
>  ==24515==  Address 0x807c6a0 is 0 bytes inside a block of size 4,096 alloc'd
>  ==24515==    at 0x4C29C0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>  ==24515==    by 0x4A5BCB: dso__load (symbol.c:1421)
>  ==24515==    by 0x4BB1AE: map__load (map.c:289)
>  ==24515==    by 0x4BB1AE: map__find_symbol (map.c:333)
>  ==24515==    by 0x4835B3: thread__find_addr_location (event.c:1300)
>  ==24515==    by 0x4B5342: add_callchain_ip (machine.c:1652)
>  ==24515==    by 0x4B5342: thread__resolve_callchain_sample (machine.c:1906)
>  ==24515==    by 0x4B9E7D: thread__resolve_callchain (machine.c:1958)
>  ==24515==    by 0x441B3E: process_event (builtin-script.c:795)
>  ==24515==    by 0x441B3E: process_sample_event (builtin-script.c:920)
>  ==24515==    by 0x4BEE29: perf_evlist__deliver_sample (session.c:1192)
>  ==24515==    by 0x4BEE29: machines__deliver_event (session.c:1229)
>  ==24515==    by 0x4BF770: perf_session__deliver_event (session.c:1286)
>  ==24515==    by 0x4BF770: ordered_events__deliver_event (session.c:114)
>  ==24515==    by 0x4C1D17: __ordered_events__flush (ordered-events.c:207)
>  ==24515==    by 0x4C1D17: ordered_events__flush.part.3 (ordered-events.c:274)
>  ==24515==    by 0x4BF44C: perf_session__process_user_event (session.c:1325)
>  ==24515==    by 0x4BF44C: perf_session__process_event (session.c:1451)
>  ==24515==    by 0x4C0EAC: __perf_session__process_events (session.c:1804)
>  ==24515==    by 0x4C0EAC: perf_session__process_events (session.c:1858)

The reason was a typo that passed global 'name' variable as the
is_regular_file argument instead dso->long_name.
Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Acked-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 40356721 ("perf symbols: Do not read symbols/data from device files")
Link: http://lkml.kernel.org/r/1466772025-17471-2-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ed7b630b
  23. 23 6月, 2016 1 次提交
  25. 31 5月, 2016 3 次提交
  27. 27 5月, 2016 1 次提交
  29. 20 5月, 2016 1 次提交
  31. 17 5月, 2016 1 次提交
  33. 12 5月, 2016 2 次提交
  35. 11 5月, 2016 1 次提交
    • C
      perf symbols: Add dso__insert_symbol function · ae93a6c7
      由 Chris Phlipot 提交于 
      The current method for inserting symbols is to use the symbols__insert()
function. However symbols__insert() does not update the dso symbol
cache.  This causes problems in the following scenario:

1. symbol not found at addr using dso__find_symbol

2. symbol inserted at addr using the existing symbols__insert function

3. symbol still not found at addr using dso__find_symbol() because cache isn't
   updated. This is undesired behavior.

The undesired behavior in (3) is addressed by creating a new function,
dso__insert_symbol() to both insert the symbol and update the symbol
cache if necessary.

If dso__insert_symbol() is used in (2) instead of symbols__insert(),
then the undesired behavior in (3) is avoided.
Signed-off-by: NChris Phlipot <cphlipot0@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1462937209-6032-2-git-send-email-cphlipot0@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ae93a6c7
  37. 10 5月, 2016 1 次提交
    • C
      perf symbols: Fix handling of zero-length symbols. · 9c7b37cd
      由 Chris Phlipot 提交于 
      This change introduces a fix to symbols__find, so that it is able to
find symbols of length zero (where start == end).

The current code has the following problem:

- The current implementation of symbols__find is unable to find any symbols
  of length zero.

- The db-export framework explicitly creates zero length symbols at
  locations where no symbol currently exists.

The combination of the two above behaviors results in behavior similar
to the example below.

1. addr_location is created for a sample, but symbol is unable to be
   resolved.

2. db export creates an "unknown" symbol of length zero at that address
   and inserts it into the dso.

3. A new sample comes in at the same address, but symbol__find is unable
   to find the zero length symbol, so it is still unresolved.

4. db export sees the symbol is unresolved, and allocated a duplicate
   symbol, even though it already did this in step 2.

This behavior continues every time an address without symbol information
is seen, which causes a very large number of these symbols to be
allocated.

The effect of this fix can be observed by looking at the contents of an
exported database before/after the fix (generated with
scripts/python/export-to-postgresql.py)

Ex.
BEFORE THE CHANGE:

  example_db=# select count(*) from symbols;
   count
  --------
   900213
  (1 row)

  example_db=# select count(*) from symbols where symbols.name='unknown';
   count
  --------
   897355
  (1 row)

  example_db=# select count(*) from symbols where symbols.name!='unknown';
   count
  -------
    2858
  (1 row)

AFTER THE CHANGE:

  example_db=# select count(*) from symbols;
   count
  -------
   25217
  (1 row)

  example_db=# select count(*) from symbols where name='unknown';
   count
  -------
   22359
  (1 row)

  example_db=# select count(*) from symbols where name!='unknown';
   count
  -------
    2858
  (1 row)
Signed-off-by: NChris Phlipot <cphlipot0@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1462612620-25008-1-git-send-email-cphlipot0@gmail.com
[ Moved the test to later in the rb_tree tests, as this not the likely case ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9c7b37cd
  39. 19 4月, 2016 1 次提交
  41. 15 4月, 2016 1 次提交
  43. 12 4月, 2016 1 次提交
    • A
      perf evsel: Allow unresolved symbol names to be printed as addresses · fd4be130
      由 Arnaldo Carvalho de Melo 提交于 
      The fprintf_sym() and fprintf_callchain() methods now allow users to
change the existing behaviour of showing "[unknown]" as the name of
unresolved symbols to instead show "[0x123456]", i.e. its address.

The current patch doesn't change tools to use this facility, the results
from 'perf trace' and 'perf script' cotinue like:

70.109 ( 0.001 ms): qemu-system-x8/10153 poll(ufds: 0x7f2d93ffe870, nfds: 1) = 0 Timeout
                                   [unknown] (/usr/lib64/libc-2.22.so)
                                   [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                   [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                   [unknown] (/usr/lib64/libspice-server.so.1.10.0)
                                   start_thread+0xca (/usr/lib64/libpthread-2.22.so)
                                   __clone+0x6d (/usr/lib64/libc-2.22.so)

The next patch will make 'perf trace' use the new formatting.
Suggested-by: NMilian Wolff <milian.wolff@kdab.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-fja1ods5vqpg42mdz09xcz3r@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fd4be130
  45. 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
  47. 26 1月, 2016 1 次提交
  49. 16 1月, 2016 1 次提交
  51. 08 1月, 2016 1 次提交
    • N
      perf report: Change default to use event group view · 1e9abf8b
      由 Namhyung Kim 提交于 
      The event group view feature is to see related events together.  To use
the group view, events should be recorded as a group with a dedicated
syntax of surrounding events by braces (-e '{ evt1, evt2, ... }').

Also 'perf report' also requires the --group option to enable it.
However it's almost always beneficial to use the group view to see the
group events as it's more expressive.  And I think it's more natural to
see events together if they are recorded as a group.

Thus this patch changes the default value to enable it.  If users don't
want to see like it and keep the original behavior, they can set the
report.group config variable to false and/or use --no-group option in
the 'perf report' command line.
Requested-by: NIngo Molnar <mingo@kernel.org>
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Taeung Song <treeze.taeung@gmail.com>
Link: http://lkml.kernel.org/r/1448807057-3506-1-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1e9abf8b
  53. 27 11月, 2015 2 次提交
  55. 13 11月, 2015 2 次提交
  57. 28 10月, 2015 2 次提交
  59. 13 10月, 2015 1 次提交
    • A
      perf symbols: Try the .debug/ DSO cache as a last resort · dc38218e
      由 Arnaldo Carvalho de Melo 提交于 
      Not as the first attempt at finding a vmlinux for the running kernel,
this way we get a more informative filename to present in tools, it will
check that the build-id is the same as the one previously loaded in the
DSO in dso->build_id, reading from /sys/kernel/notes, for instance.

E.g. in the annotation TUI, going from 'perf top', for the scsi_sg_alloc
kernel function, in the first line:

Before:

scsi_sg_alloc  /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1

After:

scsi_sg_alloc  /lib/modules/4.3.0-rc1+/build/vmlinux

And:

  # ls -la /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1
lrwxrwxrwx. 1 root root 81 Sep 22 16:11 /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1 -> ../../home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
  # file ~/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
/root/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=282777c262e6b3c0451375163c9a81c893218ab1, not stripped
  #

The same as:

  # file /lib/modules/4.3.0-rc1+/build/vmlinux
/lib/modules/4.3.0-rc1+/build/vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=282777c262e6b3c0451375163c9a81c893218ab1, not stripped

Furthermore:

  # sha256sum /lib/modules/4.3.0-rc1+/build/vmlinux
  e7a789bbdc61029ec09140c228e1dd651271f38ef0b8416c0b7d5ff727b98be2  /lib/modules/4.3.0-rc1+/build/vmlinux
  # sha256sum ~/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
  e7a789bbdc61029ec09140c228e1dd651271f38ef0b8416c0b7d5ff727b98be2  /root/.debug/home/git/build/v4.3.0-rc1+/vmlinux/282777c262e6b3c0451375163c9a81c893218ab1
  [root@zoo new]#

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.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>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-9y42ikzq3jisiddoi6f07n8z@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dc38218e