linux-toradex.git/kernel/perf_event.c, branch v2.6.32.28

Fix racy use of anon_inode_getfd() in perf_event.c

2010-07-05T18:10:30+00:00

commit ea635c64e007061f6468ece5cc9cc62d41d4ecf2 upstream.

once anon_inode_getfd() is called, you can't expect *anything* about
struct file that descriptor points to - another thread might be doing
whatever it likes with descriptor table at that point.

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

perf: Fix resource leak in failure path of perf_event_open()

2010-05-12T21:57:05+00:00

commit 048c852051d2bd5da54a4488bc1f16b0fc74c695 upstream.

perf_event_open() kfrees event after init failure which doesn't
release all resources allocated by perf_event_alloc().  Use
free_event() instead.

Signed-off-by: Tejun Heo 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
LKML-Reference: <4BDBE237.1040809@kernel.org>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_event: Fix oops triggered by cpu offline/online

2010-04-01T22:58:25+00:00

commit 220b140b52ab6cc133f674a7ffec8fa792054f25 upstream.

Anton Blanchard found that he could reliably make the kernel hit a
BUG_ON in the slab allocator by taking a cpu offline and then online
while a system-wide perf record session was running.

The reason is that when the cpu comes up, we completely reinitialize
the ctx field of the struct perf_cpu_context for the cpu.  If there is
a system-wide perf record session running, then there will be a struct
perf_event that has a reference to the context, so its refcount will
be 2.  (The perf_event has been removed from the context's group_entry
and event_entry lists by perf_event_exit_cpu(), but that doesn't
remove the perf_event's reference to the context and doesn't decrement
the context's refcount.)

When the cpu comes up, perf_event_init_cpu() gets called, and it calls
__perf_event_init_context() on the cpu's context.  That resets the
refcount to 1.  Then when the perf record session finishes and the
perf_event is closed, the refcount gets decremented to 0 and the
context gets kfreed after an RCU grace period.  Since the context
wasn't kmalloced -- it's part of a per-cpu variable -- bad things
happen.

In fact we don't need to completely reinitialize the context when the
cpu comes up.  It's sufficient to initialize the context once at boot,
but we need to do it for all possible cpus.

This moves the context initialization to happen at boot time.  With
this, we don't trash the refcount and the context never gets kfreed,
and we don't hit the BUG_ON.

Reported-by: Anton Blanchard 
Signed-off-by: Paul Mackerras 
Tested-by: Anton Blanchard 
Acked-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Honour event state for aux stream data

2010-01-25T18:49:46+00:00

commit 22e190851f8709c48baf00ed9ce6144cdc54d025 upstream.

Anton reported that perf record kept receiving events even after calling
ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP
events didn't respect the disabled state and kept flowing in.

Reported-by: Anton Blanchard 
Signed-off-by: Peter Zijlstra 
Tested-by: Anton Blanchard 
LKML-Reference: <1263459187.4244.265.camel@laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf events: Dont report side-band events on each cpu for per-task-per-cpu events

2010-01-25T18:49:45+00:00

commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.

Acme noticed that his FORK/MMAP numbers were inflated by about
the same factor as his cpu-count.

This led to the discovery of a few more sites that need to
respect the event->cpu filter.

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <20091217121830.215333434@chello.nl>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_event: Fix incorrect range check on cpu number

2009-12-18T22:06:01+00:00

commit 0f624e7e5625f4c30c836b7a5decfe2553582391 upstream.

It is quite legitimate for CPUs to be numbered sparsely, meaning
that it possible for an online CPU to have a number which is
greater than the total count of possible CPUs.

Currently find_get_context() has a sanity check on the cpu
number where it checks it against num_possible_cpus().  This
test can fail for a legitimate cpu number if the
cpu_possible_mask is sparsely populated.

This fixes the problem by checking the CPU number against
nr_cpumask_bits instead, since that is the appropriate check to
ensure that the cpu number is same to pass to cpu_isset()
subsequently.

Reported-by: Michael Neuling 
Signed-off-by: Paul Mackerras 
Tested-by: Michael Neuling 
Acked-by: Peter Zijlstra 
LKML-Reference: <20091215084032.GA18661@brick.ozlabs.ibm.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Don't free perf_mmap_data until work has been done

2009-12-18T22:03:08+00:00

commit ec70ccd806111ba3caf596def91a8580138b12db upstream.

In the CONFIG_PERF_USE_VMALLOC case, perf_mmap_data_free() only
schedules the cleanup of the perf_mmap_data struct.  In that
case we have to wait until the work has been done before we free
data.

Signed-off-by: Kristian Høgsberg 
Cc: David S. Miller 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Frederic Weisbecker 
LKML-Reference: <1259697901-1747-1-git-send-email-krh@bitplanet.net>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_event: Initialize data.period in perf_swevent_hrtimer()

2009-12-18T22:03:08+00:00

commit 59d069eb5ae9b033ed1c124c92e1532c4a958991 upstream.

In current code in perf_swevent_hrtimer(), data.period is not
initialized, The result is obvious wrong:

 # ./perf record -f -e cpu-clock make
 # ./perf report
 # Samples: 1740
 #
 # Overhead   Command                                   ......
 # ........  ........  ..........................................
 #
   1025422183050275328.00%        sh  libc-2.9.90.so ...
   1025422183050275328.00%      perl  libperl.so     ...
   1025422168240043264.00%      perl  [kernel]       ...
   1025422030011210752.00%      perl  [kernel]       ...

Signed-off-by: Xiao Guangrong 
Acked-by: Peter Zijlstra 
Cc: Frederic Weisbecker 
LKML-Reference: <4B14E220.2050107@cn.fujitsu.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf events: Don't generate events for the idle task when exclude_idle is set

2009-10-23T07:35:02+00:00

Getting samples for the idle task is often not interesting, so
don't generate them when exclude_idle is set for the event in
question.

Signed-off-by: Søren Sandmann Pedersen 
Cc: Peter Zijlstra 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Steven Rostedt 
LKML-Reference: 
Signed-off-by: Ingo Molnar

perf events: Fix swevent hrtimer sampling by keeping track of remaining time when enabling/disabling swevent hrtimers

2009-10-23T07:35:02+00:00

Make the hrtimer based events work for sysprof.

Whenever a swevent is scheduled out, the hrtimer is canceled.
When it is scheduled back in, the timer is restarted. This
happens every scheduler tick, which means the timer never
expired because it was getting repeatedly restarted over and
over with the same period.

To fix that, save the remaining time when disabling; when
reenabling, use that saved time as the period instead of the
user-specified sampling period.

Also, move the starting and stopping of the hrtimers to helper
functions instead of duplicating the code.

Signed-off-by: Søren Sandmann Pedersen 
LKML-Reference: 
Signed-off-by: Ingo Molnar