linux-toradex.git/tools/perf, branch v3.2.15

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 tools: Fix perf stack to non executable on x86_64

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

commit 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 upstream.

By adding following objects:
  bench/mem-memcpy-x86-64-asm.o
the x86_64 perf binary ended up with executable stack.

The reason was that above object are assembler sourced and is missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.

Adding section ".note.GNU-stack" definition to mentioned object, with all
flags disabled, thus omiting this object from linker stack flags decision.

Problem introduced in:

  $ git describe ea7872b
  v2.6.37-rc2-19-gea7872b

Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
Reported-by: Clark Williams 
Acked-by: Eric Dumazet 
Cc: Corey Ashford 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa 
[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
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 stat: Failure with "Operation not supported"

2011-12-05T16:32:40+00:00

perf stat is failing on PowerPC:

  Error: open_counter returned with 95 (Operation not supported). /bin/dmesg may provide additional information.

  Fatal: Not all events could be opened.

commit 370faf1dd046 (perf stat: Fail softly on unsupported events)
added a check for failure returning ENOENT, but the POWER backend
returns EOPNOTSUPP. It looks like alpha, blackfin and mips do the
same.

With the patch applied, things work as expected:

 Performance counter stats for '/bin/true':

          0.362176 task-clock                #    0.623 CPUs utilized
                 0 context-switches          #    0.000 M/sec
                 0 CPU-migrations            #    0.000 M/sec
                28 page-faults               #    0.077 M/sec
         1,677,020 cycles                    #    4.630 GHz
    stalled-cycles-frontend
    stalled-cycles-backend
           431,220 instructions              #    0.26  insns per cycle
           101,889 branches                  #  281.325 M/sec
             4,145 branch-misses             #    4.07% of all branches

       0.000581361 seconds time elapsed

Cc:  # 3.0+
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20111202093833.5fef7226@kryten
Signed-off-by: Anton Blanchard 
Signed-off-by: Arnaldo Carvalho de Melo

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