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

perf: overflow/perf_count_sw_cpu_clock crashes recent kernels

2011-08-08T17:23:22+00:00

The below patch is for -stable only, upstream has a much larger patch
that contains the below hunk in commit a8b0ca17b80e92faab46ee7179ba9e99ccb61233

Vince found that under certain circumstances software event overflows
go wrong and deadlock. Avoid trying to delete a timer from the timer
callback.

Reported-by: Vince Weaver 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman

perf: Better fit max unprivileged mlock pages for tools needs

2011-04-14T23:53:17+00:00

commit 880f57318450dbead6a03f9e31a1468924d6dd88 upstream.

The maximum kilobytes of locked memory that an unprivileged user
can reserve is of 512 kB = 128 pages by default, scaled to the
number of onlined CPUs, which fits well with the tools that use
128 data pages by default.

However tools actually use 129 pages, because they need one more
for the user control page. Thus the default mlock threshold is
not sufficient for the default tools needs and we always end up
to evaluate the constant mlock rlimit policy, which doesn't have
this scaling with the number of online CPUs.

Hence, on systems that have more than 16 CPUs, we overlap the
rlimit threshold and fail to mmap:

	$ perf record ls
	Error: failed to mmap with 1 (Operation not permitted)

Just increase the max unprivileged mlock threshold by one page
so that it supports well perf tools even after 16 CPUs.

Reported-by: Han Pingtian 
Reported-by: Peter Zijlstra 
Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Frederic Weisbecker 
Acked-by: Arnaldo Carvalho de Melo 
Cc: Stephane Eranian 
LKML-Reference: <1300904979-5508-1-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

Revert "perf: Handle stopped state with tracepoints"

2011-03-24T15:01:34+00:00

This reverts commit 6f197b73304b3bd3d5a43b931383a5331d6b2987, which was
originally commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.

This breaks the build, thanks to Jiri Slaby for pointing this out.

Reported-by: Jiri Slaby 
Cc: Frederic Weisbecker 
Signed-off-by: Greg Kroah-Hartman

perf: Handle stopped state with tracepoints

2011-03-23T20:16:52+00:00

commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.

We toggle the state from start and stop callbacks but actually
don't check it when the event triggers. Do it so that
these callbacks actually work.

Signed-off-by: Frederic Weisbecker 
Cc: Arnaldo Carvalho de Melo 
Cc: Paul Mackerras 
Cc: Stephane Eranian 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1299529629-18280-2-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

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