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

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

2010-05-12T22:02:42+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-01T23:01:30+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: Provide generic perf_sample_data initialization

2010-04-01T23:01:29+00:00

This makes it easier to extend perf_sample_data and fixes a bug on arm
and sparc, which failed to set ->raw to NULL, which can cause crashes
when combined with PERF_SAMPLE_RAW.

It also optimizes PowerPC and tracepoint, because the struct
initialization is forced to zero out the whole structure.

Signed-off-by: Peter Zijlstra 
Acked-by: Jean Pihet 
Reviewed-by: Frederic Weisbecker 
Acked-by: David S. Miller 
Cc: Jamie Iles 
Cc: Paul Mackerras 
Cc: Stephane Eranian 
LKML-Reference: <20100304140100.315416040@chello.nl>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Reimplement frequency driven sampling

2010-03-15T16:06:17+00:00

commit abd50713944c8ea9e0af5b7bffa0aacae21cc91a upstream.

There was a bug in the old period code that caused intel_pmu_enable_all()
or native_write_msr_safe() to show up quite high in the profiles.

In staring at that code it made my head hurt, so I rewrote it in a
hopefully simpler fashion. Its now fully symetric between tick and
overflow driven adjustments and uses less data to boot.

The only complication is that it basically wants to do a u128 division.
The code approximates that in a rather simple truncate until it fits
fashion, taking care to balance the terms while truncating.

This version does not generate that sampling artefact.

Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_event: Fix preempt warning in perf_clock()

2010-03-15T16:06:14+00:00

commit 24691ea964cc0123e386b661e03a86a481c6ee79 upstream.

A recent commit introduced a preemption warning for
perf_clock(), use raw_smp_processor_id() to avoid this, it
really doesn't matter which cpu we use here.

Signed-off-by: Peter Zijlstra 
LKML-Reference: <1267198583.22519.684.camel@laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_events: Fix FORK events

2010-02-14T17:10:39+00:00

Commit 22e19085 ("Honour event state for aux stream data")
introduced a bug where we would drop FORK events.

The thing is that we deliver FORK events to the child process'
event, which at that time will be PERF_EVENT_STATE_INACTIVE
because the child won't be scheduled in (we're in the middle of
fork).

Solve this twice, change the event state filter to exclude only
disabled (STATE_OFF) or worse, and deliver FORK events to the
current (parent).

Signed-off-by: Peter Zijlstra 
Cc: Anton Blanchard 
Cc: Arnaldo Carvalho de Melo 
LKML-Reference: <1266142324.5273.411.camel@laptop>
Signed-off-by: Ingo Molnar

perf: Make bp_len type to u64 generic across the arch

2010-02-04T00:07:12+00:00

Change 'bp_len' type to __u64 to make it work across archs as
the s390 architecture watch point length can be upto 2^64.

reference:
	http://lkml.org/lkml/2010/1/25/212

This is an ABI change that is not backward compatible with
the previous hardware breakpoint info layout integrated in this
development cycle, a rebuilt of perf tools is necessary for
versions based on 2.6.33-rc1 - 2.6.33-rc6 to work with a
kernel based on this patch.

Signed-off-by: Mahesh Salgaonkar 
Acked-by: Peter Zijlstra 
Cc: Ananth N Mavinakayanahalli 
Cc: "K. Prasad" 
Cc: Maneesh Soni 
Cc: Heiko Carstens 
Cc: Martin 
LKML-Reference: <20100130045518.GA20776@in.ibm.com>
Signed-off-by: Frederic Weisbecker

perf: Honour event state for aux stream data

2010-01-21T12:40:40+00:00

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>
CC: stable@kernel.org
Signed-off-by: Ingo Molnar

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

2009-12-31T19:56:24+00:00

* 'perf-fixes-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf: Fix NULL deref in inheritance code
  perf: Pass appropriate frame pointer to dump_trace()

perf: Fix NULL deref in inheritance code

2009-12-31T12:11:31+00:00

Liming found a NULL deref when a task has a perf context but no
counters  when it forks.

This can occur in two cases, a race during construction where
the fork hits after installing the context but before the first
counter gets inserted, or more reproducably, a fork after the
last counter is closed (which leaves the context around).

Reported-by: Wang Liming 
Signed-off-by: Peter Zijlstra 
Cc: Frederic Weisbecker 
Cc: Paul Mackerras 
CC: 
LKML-Reference: <1262185684.7135.222.camel@laptop>
Signed-off-by: Ingo Molnar