1. 26 6月, 2015 1 次提交
    • L
      perf symbols: Check access permission when reading symbol files · 36c8bb56
      Li Zhang 提交于
      There 2 problems when reading symbols files:
      
      *  It doesn't report any errors even if when users specify symbol
         files which don't exist with --kallsyms or --vmlinux. The result
         just shows the address without symbols, which is not what is expected.
         So it's better to report errors and exit the program.
      
      *  When using command perf report --kallsyms=/proc/kallsyms with a
         non-root user, symbols are resolved. Then select one symbol and
         annotate it, it reports the error as the following:
         Can't annotate __clear_user: No vmlinux file with build id xxx was
         found.
      
         The problem is caused by reading /proc/kcore without access permission.
         /proc/kcore requires CAP_SYS_RAWIO capability to access, so it needs to
         change access permission to allow a specific user to read /proc/kcore or
         use root to execute the perf command.
      
      This patch is to report errors when symbol files specified by users
      don't exist. And check access permission of /proc/kcore when reading it.
      Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1434704253-2632-1-git-send-email-zhlcindy@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36c8bb56
  2. 08 6月, 2015 2 次提交
    • 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
    • A
      perf machine: Fix up some more method names · 9f2de315
      Arnaldo Carvalho de Melo 提交于
      Calling the function 'machine__new_module' implies a new 'module' will
      be allocated, when in fact what is returned is a 'struct map' instance,
      that not necessarily will be instantiated, as if one already exists with
      the given module name, it will be returned instead.
      
      So be consistent with other "find and if not there, create" like
      functions, like machine__findnew_thread, machine__findnew_dso, etc, and
      rename it to machine__findnew_module_map(), that in turn will call
      machine__findnew_module_dso().
      
      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-acv830vd3hwww2ih5vjtbmu3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9f2de315
  3. 28 5月, 2015 4 次提交
  4. 27 5月, 2015 2 次提交
  5. 18 5月, 2015 2 次提交
  6. 04 5月, 2015 2 次提交
  7. 08 4月, 2015 1 次提交
  8. 25 3月, 2015 1 次提交
  9. 22 1月, 2015 1 次提交
  10. 21 1月, 2015 2 次提交
  11. 05 11月, 2014 1 次提交
    • N
      perf record: Do not save pathname in ./debug/.build-id directory for vmlinux · 00dc8657
      Namhyung Kim 提交于
      When perf record finishes a session, it pre-processes samples in order
      to write build-id info from DSOs that had samples.
      
      During this process it'll call map__load() for the kernel map, and it
      ends up calling dso__load_vmlinux_path() which replaces dso->long_name.
      
      But this function checks kernel's build-id before searching vmlinux path
      so it'll end up with a cryptic name, the pathname for the entry in the
      ~/.debug cache, which can be confusing to users.
      
      This patch adds a flag to skip the build-id check during record, so
      that it'll have the original vmlinux path for the kernel dso->long_name,
      not the entry in the ~/.debug cache.
      
      Before:
        # perf record -va sleep 3
        mmap size 528384B
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.196 MB perf.data (~8545 samples) ]
        Looking at the vmlinux_path (7 entries long)
        Using /home/namhyung/.debug/.build-id/f0/6e17aa50adf4d00b88925e03775de107611551 for symbols
      
      After:
        # perf record -va sleep 3
        mmap size 528384B
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.193 MB perf.data (~8432 samples) ]
        Looking at the vmlinux_path (7 entries long)
        Using /lib/modules/3.16.4-1-ARCH/build/vmlinux for symbols
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      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/1415063674-17206-7-git-send-email-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      00dc8657
  12. 04 11月, 2014 1 次提交
  13. 15 10月, 2014 2 次提交
  14. 18 9月, 2014 2 次提交
  15. 14 8月, 2014 2 次提交
  16. 13 8月, 2014 2 次提交
  17. 31 7月, 2014 1 次提交
  18. 17 7月, 2014 3 次提交
  19. 08 7月, 2014 1 次提交
  20. 01 6月, 2014 1 次提交
  21. 16 4月, 2014 2 次提交
  22. 25 2月, 2014 1 次提交
  23. 24 2月, 2014 1 次提交
  24. 18 2月, 2014 1 次提交
  25. 01 2月, 2014 1 次提交