Skip to content

cloud-kernel
cloud-kernel

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

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 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
  3. 01 7月, 2016 1 次提交
  5. 14 6月, 2016 1 次提交
  7. 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 次提交
  11. 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
  13. 12 5月, 2016 1 次提交
  15. 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
  17. 23 3月, 2016 1 次提交
  19. 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
  21. 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
  23. 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
  25. 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
  27. 13 11月, 2015 1 次提交
  29. 29 8月, 2015 1 次提交
  31. 21 7月, 2015 1 次提交
  33. 20 7月, 2015 1 次提交
  35. 29 5月, 2015 1 次提交
  37. 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
  39. 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
  41. 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
  43. 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
  45. 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
  47. 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
  49. 11 2月, 2015 2 次提交
  51. 09 12月, 2014 1 次提交
  53. 19 11月, 2014 1 次提交
  55. 05 11月, 2014 1 次提交
  57. 29 10月, 2014 1 次提交
  59. 12 5月, 2014 1 次提交
  61. 11 12月, 2013 1 次提交
  63. 23 10月, 2013 1 次提交
  65. 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
  67. 30 8月, 2013 1 次提交
  69. 29 8月, 2013 1 次提交
  71. 12 8月, 2013 1 次提交
  73. 08 8月, 2013 1 次提交
  75. 29 10月, 2012 1 次提交
  77. 26 10月, 2012 1 次提交