1. 23 3月, 2012 4 次提交
  2. 20 3月, 2012 1 次提交
    • P
      perf report: Add a simple GTK2-based 'perf report' browser · c31a9457
      Pekka Enberg 提交于
      This patch adds a simple GTK2-based browser to 'perf report' that's
      based on the TTY-based browser in builtin-report.c.
      
      To launch "perf report" using the new GTK interface just type:
      
        $ perf report --gtk
      
      The interface is somewhat limited in features at the moment:
      
        - No callgraph support
      
        - No KVM guest profiling support
      
        - No color coding for percentages
      
        - No sorting from the UI
      
        - ..and many, many more!
      
      That said, I think this patch a reasonable start to build future features on.
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      Cc: Colin Walters <walters@verbum.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1202231952410.6689@tux.localdomain
      [ committer note: Added #pragma to make gtk no strict prototype problem go
        away as suggested by Colin Walters modulo avoiding push/pop ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c31a9457
  3. 19 3月, 2012 2 次提交
  4. 17 3月, 2012 11 次提交
  5. 16 3月, 2012 1 次提交
  6. 14 3月, 2012 4 次提交
    • I
      perf tools, x86: Build perf on older user-space as well · eae7a755
      Ingo Molnar 提交于
      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 <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Link: http://lkml.kernel.org/n/tip-jctwg64le1w47tuaoeyftsg9@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      eae7a755
    • A
      perf tools: Use scnprintf where applicable · e7f01d1e
      Arnaldo Carvalho de Melo 提交于
      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: NAnton Blanchard <anton@samba.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e7f01d1e
    • A
      perf tools: Incorrect use of snprintf results in SEGV · b832796c
      Anton Blanchard 提交于
      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 <dsahern@gmail.com>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/20120307114249.44275ca3@krytenSigned-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b832796c
    • S
      perf record: Fix buffer overrun bug in tracepoint_id_to_path() · 8aa8a7c8
      Stephane Eranian 提交于
      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: NStephane Eranian <eranian@google.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: fweisbec@gmail.com
      Cc: dsahern@gmail.com
      Link: http://lkml.kernel.org/r/20120313155102.GA6465@quadSigned-off-by: NIngo Molnar <mingo@elte.hu>
      8aa8a7c8
  7. 13 3月, 2012 2 次提交
  8. 09 3月, 2012 10 次提交
  9. 05 3月, 2012 5 次提交