linux-stable.git/tools/perf/util, branch v3.2.14

perf tools: Use scnprintf where applicable

2012-03-23T18:21:22+00:00

commit e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 upstream.

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 
Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman

perf tools: Incorrect use of snprintf results in SEGV

2012-03-23T18:21:22+00:00

commit b832796caa1fda8516464a003c8c7cc547bc20c2 upstream.

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 
Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten
Signed-off-by: Anton Blanchard 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman

perf evsel: Fix an issue where perf report fails to show the proper percentage

2012-02-20T20:46:13+00:00

commit a4a03fc7ef89020baca4f19174e6a43767c6d78a upstream.

This patch fixes an issue where perf report shows nan% for certain
perf.data files. The below is from a report for a do_fork probe:

   -nan%           sshd  [kernel.kallsyms]  [k] do_fork
   -nan%    packagekitd  [kernel.kallsyms]  [k] do_fork
   -nan%    dbus-daemon  [kernel.kallsyms]  [k] do_fork
   -nan%           bash  [kernel.kallsyms]  [k] do_fork

A git bisect shows commit f3bda2c as the cause. However, looking back
through the git history, I saw commit 640c03c which seems to have
removed the required initialization for perf_sample->period. The problem
only started showing after commit f3bda2c. The below patch re-introduces
the initialization and it fixes the problem for me.

With the below patch, for the same perf.data:

  73.08%             bash  [kernel.kallsyms]  [k] do_fork
   8.97%      11-dhclient  [kernel.kallsyms]  [k] do_fork
   6.41%             sshd  [kernel.kallsyms]  [k] do_fork
   3.85%        20-chrony  [kernel.kallsyms]  [k] do_fork
   2.56%         sendmail  [kernel.kallsyms]  [k] do_fork

This patch applies over current linux-tip commit 9949284.

Problem introduced in:

$ git describe 640c03c
v2.6.37-rc3-83-g640c03c

Cc: Ananth N Mavinakayanahalli 
Cc: Ingo Molnar 
Cc: Robert Richter 
Cc: Srikar Dronamraju 
Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
Signed-off-by: Naveen N. Rao 
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman

perf: Fix parsing of __print_flags() in TP_printk()

2012-01-12T19:29:27+00:00

commit 49908a1b25d448d68fd26faca260e1850201575f upstream.

A update is made to the sched:sched_switch event that adds some
logic to the first parameter of the __print_flags() that shows the
state of tasks. This change cause perf to fail parsing the flags.

A simple fix is needed to have the parser be able to process ops
within the argument.

Reported-by: Andrew Vagin 
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'perf/urgent' of git://github.com/acmel/linux into perf/urgent

2011-12-07T22:23:44+00:00

perf header: Use event_name() to get an event name

2011-12-06T11:22:48+00:00

perf_evsel.name may be not initialized

Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arun Sharma 
Cc: devel@openvz.org
Link: http://lkml.kernel.org/r/1322471015-107825-2-git-send-email-avagin@openvz.org
Signed-off-by: Andrew Vagin 
Signed-off-by: Arnaldo Carvalho de Melo

perf: Fix parsing of __print_flags() in TP_printk()

2011-12-05T18:28:47+00:00

A update is made to the sched:sched_switch event that adds some
logic to the first parameter of the __print_flags() that shows the
state of tasks. This change cause perf to fail parsing the flags.

A simple fix is needed to have the parser be able to process ops
within the argument.

Cc: stable@vger.kernel.org
Reported-by: Andrew Vagin 
Signed-off-by: Steven Rostedt

perf session: Fix crash with invalid CPU list

2011-11-16T12:02:26+00:00

commit 5d67be9 added the option to specify a range of CPUs of interest,
but does not catch an invalid CPU list:

$ perf script -c foo
Segmentation fault (core dumped)

Cc: Anton Blanchard 
Link: http://lkml.kernel.org/r/1321206327-5881-1-git-send-email-dsahern@gmail.com
Signed-off-by: David Ahern 
Signed-off-by: Arnaldo Carvalho de Melo

perf python: Fix undefined symbol problem

2011-11-16T12:02:26+00:00

Recently we made perf_evsel__init call hists__init, which broke the perf
python binding:

[root@emilia linux]# ./tools/perf/python/twatch.py
Traceback (most recent call last):
  File "./tools/perf/python/twatch.py", line 16, in 
    import perf
ImportError: /home/acme/git/build/perf/python/perf.so: undefined symbol: hists__init

Fix it by moving the hists__init function to its only caller, evsel.c.

This way we avoid dragging in other parts of tools/perf/util/ to the
perf python binding.

Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-5nffmdt5mu6ozxgj54oi4qon@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

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

2011-11-07T20:38:11+00:00

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf top: Fix live annotation in the --stdio interface
  perf top tui: Don't recalc column widths considering just the first page
  perf report: Add progress bar when processing time ordered events
  perf hists browser: Warn about lost events
  perf tools: Fix a typo of command name as trace-cmd
  perf hists: Fix recalculation of total_period when sorting entries
  perf header: Fix build on old systems
  perf ui browser: Handle K_RESIZE in dialog windows
  perf ui browser: No need to switch char sets that often
  perf hists browser: Use K_TIMER
  perf ui: Rename ui__warning_paranoid to ui__error_paranoid
  perf ui: Reimplement the popup windows using libslang
  perf ui: Reimplement ui__popup_menu using ui__browser
  perf ui: Reimplement ui_helpline using libslang
  perf ui: Improve handling sigwinch a bit
  perf ui progress: Reimplement using slang
  perf evlist: Fix grouping of multiple events