user/sven/linux.git/tools, branch v3.3.4

Perf: fix build breakage

2012-04-27T17:16:33Z

[Patch not needed upstream as this is a backport build bugfix - gregkh gcc correctly complains: util/hist.c: In function ‘__hists__add_entry’: util/hist.c:240:27: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) util/hist.c:241:23: error: invalid type argument of ‘->’ (have ‘struct hist_entry’) for this new code: + if (he->ms.map != entry->ms.map) { + he->ms.map = entry->ms.map; + if (he->ms.map) + he->ms.map->referenced = true; + } because "entry" is a "struct hist_entry", not a pointer to a struct. In mainline, "entry" is a pointer to struct passed as argument to the function. So this is broken during backporting. But obviously not compile tested. Signed-off-by: Zeev Tarantov Cc: Signed-off-by: David S. Miller Cc: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf hists: Catch and handle out-of-date hist entry maps.

2012-04-22T22:38:58Z

commit 63fa471dd49e9c9ce029d910d1024330d9b1b145 upstream. When a process exec()'s, all the maps are retired, but we keep the hist entries around which hold references to those outdated maps. If the same library gets mapped in for which we have hist entries, a new map will be created. But when we take a perf entry hit within that map, we'll find the existing hist entry with the older map. This causes symbol translations to be done incorrectly. For example, the perf entry processing will lookup the correct uptodate map entry and use that to calculate the symbol and DSO relative address. But later when we update the histogram we'll translate the address using the outdated map file instead leading to conditions such as out-of-range offsets in symbol__inc_addr_samples(). Therefore, update the map of the hist_entry dynamically at lookup/ creation time. Signed-off-by: David S. Miller Link: http://lkml.kernel.org/r/20120327.031418.1220315351537060808.davem@davemloft.net Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman

perf tools, x86: Build perf on older user-space as well

2012-03-14T15:42:34Z

On ancient systems I get this build failure: util/../../../arch/x86/include/asm/unistd.h:67:29: error: asm/unistd_64.h: No such file or directory In file included from util/cache.h:7, from builtin-test.c:8: util/../perf.h: In function ‘sys_perf_event_open’:In file included from util/../perf.h:16 perf.h:170: error: ‘__NR_perf_event_open’ undeclared (first use in this function) The reason is that this old system does not have the split unistd.h headers yet, from which to pick up the syscall definitions. Add the syscall numbers to the already existing i386 and x86_64 blocks in perf.h, and also provide empty include file stubs. With this patch perf builds and works fine on 5 years old user-space as well. Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Link: http://lkml.kernel.org/n/tip-jctwg64le1w47tuaoeyftsg9@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Use scnprintf where applicable

2012-03-14T15:36:19Z

Several places were expecting that the value returned was the number of characters printed, not what would be printed if there was space. Fix it by using the scnprintf and vscnprintf variants we inherited from the kernel sources. Some corner cases where the number of printed characters were not accounted were fixed too. Reported-by: Anton Blanchard Cc: Anton Blanchard Cc: Eric B Munson Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Yanmin Zhang Cc: stable@kernel.org Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Incorrect use of snprintf results in SEGV

2012-03-14T15:36:19Z

I have a workload where perf top scribbles over the stack and we SEGV. What makes it interesting is that an snprintf is causing this. The workload is a c++ gem that has method names over 3000 characters long, but snprintf is designed to avoid overrunning buffers. So what went wrong? The problem is we assume snprintf returns the number of characters written: ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level); ... ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name); Unfortunately this is not how snprintf works. snprintf returns the number of characters that would have been written if there was enough space. In the above case, if the first snprintf returns a value larger than size, we pass a negative size into the second snprintf and happily scribble over the stack. If you have 3000 character c++ methods thats a lot of stack to trample. This patch fixes repsep_snprintf by clamping the value at size - 1 which is the maximum snprintf can write before adding the NULL terminator. I get the sinking feeling that there are a lot of other uses of snprintf that have this same bug, we should audit them all. Cc: David Ahern Cc: Eric B Munson Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Yanmin Zhang Cc: stable@kernel.org Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo

perf record: Fix buffer overrun bug in tracepoint_id_to_path()

2012-03-13T16:01:28Z

This patch fixes a buffer overrun bug in tracepoint_id_to_path(). The bug manisfested itself as a memory error reported by perf record. I ran into it with perf sched: $ perf sched rec noploop 2 noploop for 2 seconds [ perf record: Woken up 14 times to write data ] [ perf record: Captured and wrote 42.701 MB perf.data (~1865622 samples) ] Fatal: No memory to alloc tracepoints list It turned out that tracepoint_id_to_path() was reading the tracepoint id using read() but the buffer was not large enough to include the \n terminator for id with 4 digits or more. The patch fixes the problem by extending the buffer to a more reasonable size covering all possible id length include \n terminator. Note that atoll() stops at the first non digit character, thus it is not necessary to clear the buffer between each read. Signed-off-by: Stephane Eranian Acked-by: Arnaldo Carvalho de Melo Acked-by: Peter Zijlstra Cc: fweisbec@gmail.com Cc: dsahern@gmail.com Link: http://lkml.kernel.org/r/20120313155102.GA6465@quad Signed-off-by: Ingo Molnar

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-03-06T00:23:12Z

Pull perf fixes from Ingo Molnar: "It contains three cherry-picked fixes from perf/core, which turned out to be more urgent than we originally thought." * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf tools: Handle kernels that don't support attr.exclude_{guest,host} perf tools: Change perf_guest default back to false perf record: No build id option fails

perf tools: Handle kernels that don't support attr.exclude_{guest,host}

2012-03-03T15:19:56Z

Just fall back to resetting those fields, if set, warning the user that that feature is not available. If guest samples appear they will just be discarded because no struct machine will be found and thus the event will be accounted as not handled and dropped, see 0c09571. Reported-by: Namhyung Kim Tested-by: Joerg Roedel Cc: David Ahern Cc: Frederic Weisbecker Cc: Joerg Roedel Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-vuwxig36mzprl5n7nzvnxxsh@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Change perf_guest default back to false

2012-03-03T15:13:41Z

Setting perf_guest to true by default makes no sense because the perf subcommands can not setup guest symbol information and thus not process and guest samples. The only exception is perf-kvm which changes the perf_guest value on its own. So change the default for perf_guest back to false. Cc: David Ahern Cc: Ingo Molnar Cc: Jason Wang Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1328893505-4115-3-git-send-email-joerg.roedel@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Arnaldo Carvalho de Melo

perf record: No build id option fails

2012-03-03T14:02:16Z

A recent refactoring of perf-record introduced the following: perf record -a -B Couldn't generating buildids. Use --no-buildid to profile anyway. sleep: Terminated I believe the triple negative was meant to be only a double negative. :-) While I'm there, fixed the grammar on the error message. Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Robert Richter Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1328567272-13190-1-git-send-email-dsahern@gmail.com Signed-off-by: David Ahern Signed-off-by: Arnaldo Carvalho de Melo