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

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

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

2011-01-18T22:29:37+00:00

* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf: Validate cpu early in perf_event_alloc()
  perf: Find_get_context: fix the per-cpu-counter check
  perf: Fix contexted inheritance

perf: Validate cpu early in perf_event_alloc()

2011-01-18T18:34:23+00:00

Starting from perf_event_alloc()->perf_init_event(), the kernel
assumes that event->cpu is either -1 or the valid CPU number.

Change perf_event_alloc() to validate this argument early. This
also means we can remove the similar check in
find_get_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 
Cc: gregkh@suse.de
Cc: stable@kernel.org
LKML-Reference: <20110118161032.GC693@redhat.com>
Signed-off-by: Ingo Molnar

perf: Find_get_context: fix the per-cpu-counter check

2011-01-18T18:34:23+00:00

If task == NULL, find_get_context() should always check that cpu
is correct.

Afaics, the bug was introduced by 38a81da2 "perf events: Clean
up pid passing", but even before that commit "&& cpu != -1" was
not exactly right, -ESRCH from find_task_by_vpid() is not
accurate.

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 
Cc: gregkh@suse.de
Cc: stable@kernel.org
LKML-Reference: <20110118161008.GB693@redhat.com>
Signed-off-by: Ingo Molnar

perf: Fix contexted inheritance

2011-01-18T14:10:35+00:00

Linus reported that the RCU lockdep annotation bits triggered for this
rcu_dereference() because we're not holding rcu_read_lock().

Going over the code I cannot convince myself its correct:

 - holding a ref on the parent_ctx, doesn't avoid it being uncloned
   concurrently (as the comment says), so we can race with a free.

 - holding parent_ctx->mutex doesn't avoid the above free from taking
   place either, it would at best avoid parent_ctx from being freed.

I.e. the warning is correct. To fix the bug, serialize against the
unclone_ctx() call by extending the reach of the parent_ctx->lock.

Reported-by: Linus Torvalds 
Signed-off-by: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Paul E. McKenney 
LKML-Reference: 
Signed-off-by: Ingo Molnar