Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 12 8月, 2017 1 次提交
  3. 09 6月, 2017 2 次提交
  5. 06 6月, 2017 1 次提交
    • N
      perf symbols: Use correct filename for compressed modules in build-id cache · a09935b8
      由 Namhyung Kim 提交于 
      The decompress_kmodule() decompresses kernel modules in order to load
symbols from it.  In the DSO_BINARY_TYPE__BUILD_ID_CACHE case, it needs
the full file path to extract the file extension to determine the
decompression method.  But overwriting 'name' will fail the
decompression since it might point to a non-existing old file.

Instead, use dso->long_name for having the correct extension and use the
real filename to decompress.

In the DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP case, both names should
be the same.  This allows resolving symbols in the old modules.

Before:

  $ perf report -i perf.data.old | grep scsi_mod
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000004aa6
     0.00%  as       [scsi_mod]    [k] 0x00000000000099e1
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000009830
     0.00%  cc1      [scsi_mod]    [k] 0x0000000000001b8f

After:

     0.00%  cc1      [scsi_mod]    [k] scsi_handle_queue_ramp_up
     0.00%  as       [scsi_mod]    [k] scsi_sg_alloc
     0.00%  cc1      [scsi_mod]    [k] scsi_setup_cmnd
     0.00%  cc1      [scsi_mod]    [k] scsi_get_command
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170531120105.21731-3-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a09935b8
  7. 20 4月, 2017 1 次提交
  9. 27 3月, 2017 1 次提交
  11. 21 3月, 2017 1 次提交
  13. 20 2月, 2017 1 次提交
  15. 04 1月, 2017 1 次提交
  17. 05 9月, 2016 2 次提交
  19. 01 9月, 2016 4 次提交
    • A
      perf symbols: Fixup symbol sizes before picking best ones · 432746f8
      由 Arnaldo Carvalho de Melo 提交于 
      When we call symbol__fixup_duplicate() we use algorithms to pick the
"best" symbols for cases where there are various functions/aliases to an
address, and those check zero size symbols, which, before calling
symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file.

So first fixup the end, then fixup the duplicates.

Found while trying to figure out why 'perf test vmlinux' failed, see the
output of 'perf test -v vmlinux' to see cases where the symbols picked
as best for vmlinux don't match the ones picked for kallsyms.

Cc: Anton Blanchard <anton@samba.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 694bf407 ("perf symbols: Add some heuristics for choosing the best duplicate symbol")
Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      432746f8
    • A
      perf symbols: Check symbol_conf.allow_aliases for kallsyms loading too · c97b40e4
      由 Arnaldo Carvalho de Melo 提交于 
      We can allow aliases to be kept, but we were checking this just when
loading vmlinux files, be consistent, do it for any symbol table loading
code that calls symbol__fixup_duplicate() by making this function check
.allow_aliases instead.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 680d926a ("perf symbols: Allow symbol alias when loading map for symbol name")
Link: http://lkml.kernel.org/n/tip-z0avp0s6cfjckc4xj3pdfjdz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c97b40e4
    • M
      perf probe: Ignore vmlinux buildid if offline kernel is given · 428aff82
      由 Masami Hiramatsu 提交于 
      Ignore the buildid of running kernel when both of --definition and
--vmlinux is given because that kernel should be off-line.

This also skips post-processing of kprobe event for relocating symbol
and checking blacklist, because it can not be done on off-line kernel.

E.g. without this fix perf shows an error as below
  ----
  $ perf probe --vmlinux=./vmlinux-arm --definition do_sys_open
  ./vmlinux-arm with build id 7a1f76dd56e9c4da707cd3d6333f50748141434b not found, continuing without symbols
  Failed to find symbol do_sys_open in kernel
    Error: Failed to add events.
  ----
with this fix, we can get the definition
  ----
  $ perf probe --vmlinux=./vmlinux-arm --definition do_sys_open
  p:probe/do_sys_open do_sys_open+0
  ----
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/147214228193.23638.12581984840822162131.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      428aff82
    • M
      perf symbols: Demangle symbols for synthesized @plt entries. · 2a8d41b4
      由 Milian Wolff 提交于 
      The symbols in the synthesized @plt entries where not demangled before,
i.e. we could end up with entries such as:

    $ perf report
    Samples: 7K of event 'cycles:ppp', Event count (approx.): 6223833141
    Children      Self  Command          Shared Object           Symbol
    -   93.63%    28.89%  lab_mandelbrot   lab_mandelbrot        [.] main
        - 73.81% main
            - 33.57% hypot
              27.76% __hypot_finite
              15.97% __muldc3
               2.90% __muldc3@plt
               2.40% _ZNK6QImage6heightEv@plt
             + 2.14% QColor::rgb
               1.94% _ZNK6QImage5widthEv@plt
               1.92% cabs@plt

This patch remedies this issue by also applying demangling to the
synthesized symbols. The output for the above is now:

    $ perf report
    Samples: 7K of event 'cycles:ppp', Event count (approx.): 6223833141
    Children      Self  Command          Shared Object           Symbol
    -   93.63%    28.89%  lab_mandelbrot   lab_mandelbrot        [.] main
        - 73.81% main
            - 33.57% hypot
              27.76% __hypot_finite
              15.97% __muldc3
               2.90% __muldc3@plt
               2.40% QImage::height() const@plt
             + 2.14% QColor::rgb
               1.94% QImage::width() const@plt
               1.92% cabs@plt
Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
LPU-Reference: 20160830114102.30863-1-milian.wolff@kdab.com
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2a8d41b4
  21. 16 8月, 2016 1 次提交
  23. 13 7月, 2016 3 次提交
    • D
      perf symbols: Add Rust demangling · cae15db7
      由 David Tolnay 提交于 
      Rust demangling is another step after bfd demangling. Add a diagnosis to
identify mangled Rust symbols based on the hash that the Rust mangler appends
as the last path component, as well as other characteristics.  Add a demangler
to reconstruct the original symbol.

Committer notes:

How I tested it:

Enabled COPR on Fedora 24 and then installed the 'rust-binary' package,
with it:

  $ cat src/main.rs
  fn main() {
      println!("Hello, world!");
  }
  $ cat Cargo.toml
  [package]

  name = "hello_world"
  version = "0.0.1"
  authors = [ "Arnaldo Carvalho de Melo <acme@kernel.org>" ]

  $ perf record cargo bench
   Compiling hello_world v0.0.1 (file:///home/acme/projects/hello_world)
     Running target/release/hello_world-d4b9dab4b2a47d75

  running 0 tests

  test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.096 MB perf.data (1457 samples) ]
  $

Before this patch:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .............................................................................................................
  #
       1.78%  rustc    [.] rbml::reader::maybe_get_doc::hb9d387df6024b15b
       1.50%  rustc    [.] _$LT$reader..DocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::hd9af9e60d79a35c8
       1.20%  rustc    [.] rbml::reader::doc_at::hc88107fba445af31
       0.46%  rustc    [.] _$LT$reader..TaggedDocsIterator$LT$$u27$a$GT$$u20$as$u20$std..iter..Iterator$GT$::next::h0cb40e696e4bb489
       0.35%  rustc    [.] rbml::reader::Decoder::_next_int::h66eef7825a398bc3
       0.29%  rustc    [.] rbml::reader::Decoder::_next_sub::h8e5266005580b836
       0.15%  rustc    [.] rbml::reader::get_doc::h094521c645459139
       0.14%  rustc    [.] _$LT$reader..Decoder$LT$$u27$doc$GT$$u20$as$u20$serialize..Decoder$GT$::read_u32::h0acea2fff9669327
       0.07%  rustc    [.] rbml::reader::Decoder::next_doc::h6714d469c9dfaf91
       0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
       0.06%  rustc    [.] _fini
  $

After:

  $ perf report --stdio --dsos librbml-e8edd0fd.so
  # dso: librbml-e8edd0fd.so
  #
  # Total Lost Samples: 0
  #
  # Samples: 1K of event 'cycles:u'
  # Event count (approx.): 979599126
  #
  # Overhead  Command  Symbol
  # ........  .......  .................................................................
  #
     1.78%  rustc    [.] rbml::reader::maybe_get_doc
     1.50%  rustc    [.] <reader::DocsIterator<'a> as std::iter::Iterator>::next
     1.20%  rustc    [.] rbml::reader::doc_at
     0.46%  rustc    [.] <reader::TaggedDocsIterator<'a> as std::iter::Iterator>::next
     0.35%  rustc    [.] rbml::reader::Decoder::_next_int
     0.29%  rustc    [.] rbml::reader::Decoder::_next_sub
     0.15%  rustc    [.] rbml::reader::get_doc
     0.14%  rustc    [.] <reader::Decoder<'doc> as serialize::Decoder>::read_u32
     0.07%  rustc    [.] rbml::reader::Decoder::next_doc
     0.07%  rustc    [.] _ZN4rbml6reader10doc_as_u6417h930b740aa94f1d3aE@plt
     0.06%  rustc    [.] _fini
  $
Signed-off-by: NDavid Tolnay <dtolnay@gmail.com>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/5780B7FA.3030602@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cae15db7
    • 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
    • A
      perf symbols: Provide a GElf_Nhdr typedef · cc31078c
      由 Arnaldo Carvalho de Melo 提交于 
      This one can be safely defined to be Elf64_Nhdr, as it is in elfutils's
libelf, but not on musl libc, as both Elf64_Nhdr and  Elf32_Nhdr have
the same layout.

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-w8z8614l03lc8bip4ijbywbt@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      cc31078c
  25. 05 7月, 2016 2 次提交
    • H
      perf sdt: ELF support for SDT · 060fa0c7
      由 Hemant Kumar 提交于 
      This patch serves the initial support to identify and list SDT events in
binaries.  When programs containing SDT markers are compiled, gcc with
the help of assembler directives identifies them and places them in the
section ".note.stapsdt".

To find these markers from the binaries, one needs to traverse through
this section and parse the relevant details like the name, type and
location of the marker. Also, the original location could be skewed due
to the effect of prelinking. If that is the case, the locations need to
be adjusted.

The functions in this patch open a given ELF, find out the SDT section,
parse the relevant details, adjust the location (if necessary) and
populate them in a list.

A typical note entry in ".note.stapsdt" section is as follows :

                                 |--nhdr.n_namesz--|
                ------------------------------------
                |      nhdr      |     "stapsdt"   |
        -----   |----------------------------------|
         |      |  <location>       <base_address> |
         |      |  <semaphore>                     |
nhdr.n_descsize |  "provider_name"   "note_name"   |
         |      |   <args>                         |
        -----   |----------------------------------|
                |      nhdr      |     "stapsdt"   |
                |...

The above shows an excerpt from the section ".note.stapsdt".  'nhdr' is
a structure which has the note name size (n_namesz), note description
size (n_desc_sz) and note type (n_type).

So, in order to parse the note note info, we need nhdr to tell us where
to start from.  As can be seen from <sys/sdt.h>, the name of the SDT
notes given is "stapsdt".  But this is not the identifier of the note.

After that, we go to description of the note to find out its location, the
address of the ".stapsdt.base" section and the semaphore address.
Then, we find the provider name and the SDT marker name and then follow the
arguments.
Signed-off-by: NHemant Kumar <hemant@linux.vnet.ibm.com>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146736022628.27797.1201368329092908163.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      060fa0c7
    • A
      perf build: Add feature detection for libelf's elf_getshdrstrndx() · 2492c465
      由 Arnaldo Carvalho de Melo 提交于 
      That appeared after 0.140, and will be used in the SDT code, so, to
avoid bisection break on older systems, add a feature detection and
provide a stub with a pr_debug() to keep it building.

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: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/n/tip-80y0eldgweorqnwha9rvfxjr@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2492c465
  27. 06 5月, 2016 1 次提交
  29. 08 4月, 2016 1 次提交
    • W
      perf symbols: Adjust symbol for shared objects · 99e87f7b
      由 Wang Nan 提交于 
      He Kuang reported a problem that perf fails to get correct symbol on
Android platform in [1]. The problem can be reproduced on normal x86_64
platform. I will describe the reproducing steps in detail at the end of
commit message.

The reason of this problem is the missing of symbol adjustment for normal
shared objects. In most of the cases skipping adjustment is okay. However,
when '.text' section have different 'address' and 'offset' the result is wrong.
I checked all shared objects in my working platform, only wine dll objects and
debug objects (in .debug) have this problem. However, it is common on Android.
For example:

 $ readelf -S ./libsurfaceflinger.so | grep \.text
   [10] .text             PROGBITS         0000000000029030  00012030

This patch enables symbol adjustment for dynamic objects so the symbol
address got from elfutils would be adjusted correctly.

Now nearly all types of ELF files should adjust symbols. Makes
ss->adjust_symbols default to true.

Steps to reproduce the problem:

  $ cat ./Makefile
  PWD := $(shell pwd)
  LDFLAGS += "-Wl,-rpath=$(PWD)"
  CFLAGS += -g
  main: main.c libbuggy.so
  libbuggy.so: buggy.c
	gcc -g -shared -fPIC -Wl,-Ttext-segment=0x200000 $< -o $@
  clean:
	rm -rf main libbuggy.so *.o

  $ cat ./buggy.c
  int fib(int x)
  {
      return (x == 0) ? 1 : (x == 1) ? 1 : fib(x - 1) + fib(x - 2);
  }

  $ cat ./main.c
  #include <stdio.h>

  extern int fib(int x);
  int main()
  {
     int i;

     for (i = 0; i < 40; i++)
         printf("%d\n", fib(i));
     return 0;
 }

 $ make
 $ perf record ./main
 ...
 $ perf report --stdio
 # Overhead  Command  Shared Object      Symbol
 # ........  .......  .................  ...............................
 #
     14.97%  main     libbuggy.so        [.] 0x000000000000066c
      8.68%  main     libbuggy.so        [.] 0x00000000000006aa
      8.52%  main     libbuggy.so        [.] fib@plt
      7.95%  main     libbuggy.so        [.] 0x0000000000000664
      5.94%  main     libbuggy.so        [.] 0x00000000000006a9
      5.35%  main     libbuggy.so        [.] 0x0000000000000678
 ...

The correct result should be (after this patch):

  # Overhead  Command  Shared Object      Symbol
  # ........  .......  .................  ...............................
  #
      91.47%  main     libbuggy.so        [.] fib
       8.52%  main     libbuggy.so        [.] fib@plt
       0.00%  main     [kernel.kallsyms]  [k] kmem_cache_free

[1] http://lkml.kernel.org/g/1452567507-54013-1-git-send-email-hekuang@huawei.comSigned-off-by: NWang Nan <wangnan0@huawei.com>
Acked-by: NNamhyung Kim <namhyung@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Cody P Schafer <dev@codyps.com>
Cc: He Kuang <hekuang@huawei.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: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1460024671-64774-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      99e87f7b
  31. 19 3月, 2016 1 次提交
  33. 05 2月, 2016 1 次提交
  35. 11 12月, 2015 1 次提交
    • M
      perf symbols: Fix dso__load_sym to put dso · e7a7865c
      由 Masami Hiramatsu 提交于 
      Fix dso__load_sym to put dso because dsos__add already got it.

Refcnt debugger explain the problem:
  ----
  ==== [0] ====
  Unreclaimed dso: 0x19dd200
  Refcount +1 => 1 at
    ./perf(dso__new+0x1ff) [0x4a62df]
    ./perf(dso__load_sym+0xe89) [0x503509]
    ./perf(dso__load_vmlinux+0xbf) [0x4aa77f]
    ./perf(dso__load_vmlinux_path+0x8c) [0x4aa8dc]
    ./perf() [0x50539a]
    ./perf(convert_perf_probe_events+0xd79) [0x50ad39]
    ./perf() [0x45600f]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f74dd0efaf5]
    ./perf() [0x4220a9]
  Refcount +1 => 2 at
    ./perf(dso__get+0x34) [0x4a65f4]
    ./perf(map__new2+0x76) [0x4be216]
    ./perf(dso__load_sym+0xee1) [0x503561]
    ./perf(dso__load_vmlinux+0xbf) [0x4aa77f]
    ./perf(dso__load_vmlinux_path+0x8c) [0x4aa8dc]
    ./perf() [0x50539a]
    ./perf(convert_perf_probe_events+0xd79) [0x50ad39]
    ./perf() [0x45600f]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f74dd0efaf5]
    ./perf() [0x4220a9]
  Refcount +1 => 3 at
    ./perf(dsos__add+0xf3) [0x4a6bc3]
    ./perf(dso__load_sym+0xfc1) [0x503641]
    ./perf(dso__load_vmlinux+0xbf) [0x4aa77f]
    ./perf(dso__load_vmlinux_path+0x8c) [0x4aa8dc]
    ./perf() [0x50539a]
    ./perf(convert_perf_probe_events+0xd79) [0x50ad39]
    ./perf() [0x45600f]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f74dd0efaf5]
    ./perf() [0x4220a9]
  Refcount -1 => 2 at
    ./perf(dso__put+0x2f) [0x4a664f]
    ./perf(map_groups__exit+0xb9) [0x4bee29]
    ./perf(machine__delete+0xb0) [0x4b93d0]
    ./perf(exit_probe_symbol_maps+0x28) [0x506718]
    ./perf() [0x45628a]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f74dd0efaf5]
    ./perf() [0x4220a9]
  Refcount -1 => 1 at
    ./perf(dso__put+0x2f) [0x4a664f]
    ./perf(machine__delete+0xfe) [0x4b941e]
    ./perf(exit_probe_symbol_maps+0x28) [0x506718]
    ./perf() [0x45628a]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f74dd0efaf5]
    ./perf() [0x4220a9]
  ----
So, in the dso__load_sym, dso is gotten 3 times, by dso__new,
map__new2, and dsos__add. The last 2 is actually released by
map_groups and machine__delete correspondingly. However, the
first reference by dso__new, is never released.

Committer note:

Changed the place where the reference count is dropped to:

Fix it by dropping it right after creating curr_map, since we know that
either that operation failed and we need to drop the dso refcount or
that it succeed and we have it referenced via curr_map->dso.

Then only drop the curr_map refcount after we call dsos__add() to make
sure we hold a reference to it via curr_map->dso.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20151209021118.10245.49869.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e7a7865c
  37. 20 11月, 2015 1 次提交
    • M
      perf tools: Fix to put new map after inserting to map_groups in dso__load_sym · 8d5c340d
      由 Masami Hiramatsu 提交于 
      Fix dso__load_sym to put the map object which is already
insterted to kmaps.

Refcnt debugger shows
  ==== [0] ====
  Unreclaimed map: 0x39113e0
  Refcount +1 => 1 at
    ./perf(map__new2+0xb5) [0x4be155]
    ./perf(dso__load_sym+0xee1) [0x503461]
    ./perf(dso__load_vmlinux+0xbf) [0x4aa6df]
    ./perf(dso__load_vmlinux_path+0x8c) [0x4aa83c]
    ./perf() [0x50528a]
    ./perf(convert_perf_probe_events+0xd79) [0x50ac29]
    ./perf() [0x45600f]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f152368baf5]
    ./perf() [0x4220a9]
  Refcount +1 => 2 at
    ./perf(maps__insert+0x9a) [0x4bfffa]
    ./perf(dso__load_sym+0xf89) [0x503509]
    ./perf(dso__load_vmlinux+0xbf) [0x4aa6df]
    ./perf(dso__load_vmlinux_path+0x8c) [0x4aa83c]
    ./perf() [0x50528a]
    ./perf(convert_perf_probe_events+0xd79) [0x50ac29]
    ./perf() [0x45600f]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f152368baf5]
    ./perf() [0x4220a9]
  Refcount -1 => 1 at
    ./perf(map_groups__exit+0x94) [0x4bed04]
    ./perf(machine__delete+0xb0) [0x4b9300]
    ./perf(exit_probe_symbol_maps+0x28) [0x506608]
    ./perf() [0x45628a]
    ./perf(cmd_probe+0x6c) [0x4566bc]
    ./perf() [0x47abc5]
    ./perf(main+0x610) [0x421f90]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f152368baf5]
    ./perf() [0x4220a9]

This means that the dso__load_sym calls map__new2 and maps_insert, both
of them bump the map refcount, but map_groups__exit will drop just one
reference.

Fix it by dropping the refcount after inserting it into kmaps.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20151118064026.30709.50038.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8d5c340d
  39. 25 9月, 2015 1 次提交
    • A
      perf tools: Fix copying of /proc/kcore · b5cabbcb
      由 Adrian Hunter 提交于 
      A copy of /proc/kcore containing the kernel text can be made to the
buildid cache. e.g.

	perf buildid-cache -v -k /proc/kcore

To workaround objdump limitations, a copy is also made when annotating
against /proc/kcore.

The copying process stops working from libelf about v1.62 onwards (the
problem was found with v1.63).

The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails
because additional validation has been added to gelf_getphdr().

The use of gelf_getphdr() is a misguided attempt to get default
initialization of the Gelf_Phdr structure.  That should not be
necessary because every member of the Gelf_Phdr structure is
subsequently assigned.  So just remove the call to gelf_getphdr().

Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be
removed also.

Committer notes:

Note to stable@kernel.org, from Adrian in the cover letter for this
patchkit:

The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think
it is important enough for stable.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b5cabbcb
  41. 18 9月, 2015 1 次提交
    • A
      Revert "perf symbols: Fix mismatched declarations for elf_getphdrnum" · 179f36dd
      由 Arnaldo Carvalho de Melo 提交于 
      This reverts commit f785f235.

We have a test to check if elf_getphdrnum() is present, so, if it fails,
we'll get:

  [acme@rhel5 linux]$ cat /tmp/build/perf/feature/test-libelf-getphdrnum.make.output
  cc1: warnings being treated as errors
  test-libelf-getphdrnum.c: In function ‘main’:
  test-libelf-getphdrnum.c:7: warning: implicit declaration of function ‘elf_getphdrnum’
  [acme@rhel5 linux]$

And this block will not be compiled:

  #ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
  static int elf_getphdrnum(Elf *elf, size_t *dst)
  ...
  #endif

So, if elf_getphdrnum() is being defined somewhere, there is a problem
with the test that is not detecting that function, go fix it.
Reported-by: NVinson Lee <vlee@twopensource.com>
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@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Victor Kamensky <victor.kamensky@linaro.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-qn459fal6acvcvm50i8zxx9k@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      179f36dd
  43. 17 8月, 2015 1 次提交
  45. 29 7月, 2015 1 次提交
    • A
      perf symbols: Fix mismatched declarations for elf_getphdrnum · f785f235
      由 Arnaldo Carvalho de Melo 提交于 
      When HAVE_ELF_GETPHDRNUM_SUPPORT is false we trip on this problem:

    CC       /tmp/build/perf/util/symbol-elf.o
  util/symbol-elf.c:41:12: error: static declaration of ‘elf_getphdrnum’ follows non-static declaration
   static int elf_getphdrnum(Elf *elf, size_t *dst)
            ^
  In file included from util/symbol.h:19:0,
                   from util/symbol-elf.c:8:
  /usr/include/libelf.h:206:12: note: previous declaration of ‘elf_getphdrnum’ was here
   extern int elf_getphdrnum (Elf *__elf, size_t *__dst);
            ^
    MKDIR    /tmp/build/perf/bench/
  /home/git/linux/tools/build/Makefile.build:68: recipe for target '/tmp/build/perf/util/symbol-elf.o' failed
  make[3]: *** [/tmp/build/perf/util/symbol-elf.o] Error 1

Fix it.

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>
Link: http://lkml.kernel.org/n/tip-qcmekyfedmov4sxr0wahcikr@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f785f235
  47. 08 6月, 2015 1 次提交
    • A
      perf tools: Reference count struct dso · d3a7c489
      由 Arnaldo Carvalho de Melo 提交于 
      This has a different model than the 'thread' and 'map' struct lifetimes:
there is not a definitive "don't use this DSO anymore" event, i.e. we may
get many 'struct map' holding references to the '/usr/lib64/libc-2.20.so'
DSO but then at some point some DSO may have no references but we still
don't want to straight away release its resources, because "soon" we may
get a new 'struct map' that needs it and we want to reuse its symtab or
other resources.

So we need some way to garbage collect it when crossing some memory
usage threshold, which is left for anoter patch, for now it is
sufficient to release it when calling dsos__exit(), i.e. when deleting
the whole list as part of deleting the 'struct machine' containing it,
which will leave only referenced objects being used.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lkml.kernel.org/n/tip-majzgz07cm90t2tejrjy4clf@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d3a7c489
  49. 29 5月, 2015 1 次提交
  51. 28 5月, 2015 1 次提交
    • A
      perf tools: Reference count struct map · 84c2cafa
      由 Arnaldo Carvalho de Melo 提交于 
      We have pointers to struct map instances in several places, like in the
hist_entry instances, so we need a way to know when we can destroy them,
otherwise we may either keep leaking them or end up referencing deleted
instances.

Start fixing it by reference counting them.

This patch puts the reference count for struct map in place, replacing
direct map__delete() calls with map__put() ones and then grabbing a
reference count when adding it to the maps struct where maps for a
struct thread are kept.

Next we'll grab reference counts when setting pointers to struct map
instances, in places like in the hist_entry code.

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-wi19xczk0t2a41r1i2chuio5@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      84c2cafa
  53. 04 5月, 2015 3 次提交
  55. 08 4月, 2015 1 次提交
  57. 24 3月, 2015 1 次提交
    • A
      perf symbols: Save DSO loading errno to better report errors · 18425f13
      由 Arnaldo Carvalho de Melo 提交于 
      Before, when some problem happened while trying to load the kernel
symtab, 'perf top' would show:

      ┌─Warning:───────────────────────────┐
      │The vmlinux file can't be used.     │
      │Kernel samples will not be resolved.│
      │                                    │
      │                                    │
      │Press any key...                    │
      └────────────────────────────────────┘

Now, it reports:

  # perf top --vmlinux /dev/null

      ┌─Warning:───────────────────────────────────────────┐
      │The /tmp/passwd file can't be used: Invalid ELF file│
      │Kernel samples will not be resolved.                │
      │                                                    │
      │                                                    │
      │Press any key...                                    │
      └────────────────────────────────────────────────────┘

This is possible because we now register the reason for not being able
to load the symtab in the dso->load_errno member, and provide a
dso__strerror_load() routine to format this error into a strerror like
string with a short reason for the error while loading.

That can be just forwarding the dso__strerror_load() call to
strerror_r(), or, for a separate errno range providing a custom message.
Reported-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NJiri Olsa <jolsa@kernel.org>
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: Namhyung Kim <namhyung@kernel.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-u5rb5uq63xqhkfb8uv2lxd5u@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      18425f13
  59. 23 3月, 2015 1 次提交