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

perf: Fix tear-down of inherited group events

2011-03-27T18:36:35+00:00

commit 38b435b16c36b0d863efcf3f07b34a6fac9873fd upstream.

When destroying inherited events, we need to destroy groups too,
otherwise the event iteration in perf_event_exit_task_context() will
miss group siblings and we leak events with all the consequences.

Reported-and-tested-by: Vince Weaver 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1300196470.2203.61.camel@twins>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Handle stopped state with tracepoints

2011-03-23T20:04:05+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

perf: Fix the software events state check

2011-03-23T20:04:04+00:00

commit 91b2f482e62ad0d444222253026a5cbca28c4ab9 upstream.

Fix the mistakenly inverted check of events state.

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

perf: Fix throttle logic

2011-02-16T12:25:29+00:00

It was possible to call pmu::start() on an already running event. In
particular this lead so some wreckage as the hrtimer events would
re-initialize active timers.

This was due to throttled events being activated again by scheduling.
Scheduling in a context would add and force start events, resulting in
running events with a possible throttle status. The next tick to hit
that task will then try to unthrottle the event and call ->start() on
an already running event.

Reported-by: Jeff Moyer 
Cc: 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar

perf: Fix reading in perf_event_read()

2011-02-03T11:15:46+00:00

It is quite possible for the event to have been disabled between
perf_event_read() sending the IPI and the CPU servicing the IPI and
calling __perf_event_read(), hence revalidate the state.

Reported-by: Stephane Eranian 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar

perf: Fix alloc_callchain_buffers()

2011-01-27T18:21:50+00:00

Commit 927c7a9e92c4 ("perf: Fix race in callchains") introduced
a mismatch in the sizing of struct callchain_cpus_entries.

nr_cpu_ids must be used instead of num_possible_cpus(), or we
might get out of bound memory accesses on some machines.

Signed-off-by: Eric Dumazet 
Cc: Frederic Weisbecker 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: David Miller 
Cc: Stephane Eranian 
CC: stable@kernel.org
LKML-Reference: <1295980851.3588.351.camel@edumazet-laptop>
Signed-off-by: Ingo Molnar

perf: perf_event_exit_task_context: s/rcu_dereference/rcu_dereference_raw/

2011-01-21T21:08:16+00:00

In theory, almost every user of task->child->perf_event_ctxp[]
is wrong. find_get_context() can install the new context at any
moment, we need read_barrier_depends().

dbe08d82ce3967ccdf459f7951d02589cf967300 "perf: Fix
find_get_context() vs perf_event_exit_task() race" added
rcu_dereference() into perf_event_exit_task_context() to make
the precedent, but this makes __rcu_dereference_check() unhappy.
Use rcu_dereference_raw() to shut up the warning.

Reported-by: Ingo Molnar 
Signed-off-by: Oleg Nesterov 
Cc: acme@redhat.com
Cc: paulus@samba.org
Cc: stern@rowland.harvard.edu
Cc: a.p.zijlstra@chello.nl
Cc: fweisbec@gmail.com
Cc: roland@redhat.com
Cc: prasad@linux.vnet.ibm.com
Cc: Paul E. McKenney 
LKML-Reference: <20110121174547.GA8796@redhat.com>
Signed-off-by: Ingo Molnar

perf: Annotate cpuctx->ctx.mutex to avoid a lockdep splat

2011-01-21T15:32:42+00:00

Lockdep spotted:

	loop_1b_instruc/1899 is trying to acquire lock:
	 (event_mutex){+.+.+.}, at: [] perf_trace_init+0x3b/0x2f7

	but task is already holding lock:
	 (&ctx->mutex){+.+.+.}, at: [] perf_event_init_context+0xc0/0x218

	which lock already depends on the new lock.

	the existing dependency chain (in reverse order) is:

	-> #3 (&ctx->mutex){+.+.+.}:
	-> #2 (cpu_hotplug.lock){+.+.+.}:
	-> #1 (module_mutex){+.+...}:
	-> #0 (event_mutex){+.+.+.}:

But because the deadlock would be cpuhotplug (cpu-event) vs fork
(task-event) it cannot, in fact, happen. We can annotate this by giving the
perf_event_context used for the cpuctx a different lock class from those
used by tasks.

Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar

perf: Fix perf_event_init_task()/perf_event_free_task() interaction

2011-01-19T19:04:28+00:00

perf_event_init_task() should clear child->perf_event_ctxp[]
before anything else. Otherwise, if
perf_event_init_context(perf_hw_context) fails,
perf_event_free_task() can free perf_event_ctxp[perf_sw_context]
copied from parent->perf_event_ctxp[] by dup_task_struct().

Also move the initialization of perf_event_mutex and
perf_event_list from perf_event_init_context() to
perf_event_init_context().

Signed-off-by: Oleg Nesterov 
Acked-by: Peter Zijlstra 
Cc: Alan Stern 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Paul Mackerras 
Cc: Prasad 
Cc: Roland McGrath 
LKML-Reference: <20110119182228.GC12183@redhat.com>
Signed-off-by: Ingo Molnar

perf: Fix find_get_context() vs perf_event_exit_task() race

2011-01-19T19:04:27+00:00

find_get_context() must not install the new perf_event_context
if the task has already passed perf_event_exit_task().

If nothing else, this means the memory leak. Initially
ctx->refcount == 2, it is supposed that
perf_event_exit_task_context() should participate and do the
necessary put_ctx().

find_lively_task_by_vpid() checks PF_EXITING but this buys
nothing, by the time we call find_get_context() this task can be
already dead. To the point, cmpxchg() can succeed when the task
has already done the last schedule().

Change find_get_context() to populate task->perf_event_ctxp[]
under task->perf_event_mutex, this way we can trust PF_EXITING
because perf_event_exit_task() takes the same mutex.

Also, change perf_event_exit_task_context() to use
rcu_dereference(). Probably this is not strictly needed, but
with or without this change find_get_context() can race with
setup_new_exec()->perf_event_exit_task(), rcu_dereference()
looks better.

Signed-off-by: Oleg Nesterov 
Acked-by: Peter Zijlstra 
Cc: Alan Stern 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Paul Mackerras 
Cc: Prasad 
Cc: Roland McGrath 
LKML-Reference: <20110119182207.GB12183@redhat.com>
Signed-off-by: Ingo Molnar