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

perf: Fix throttle logic

2011-02-24T22:54:40+00:00

commit 4fe757dd48a9e95e1a071291f15dda5421dacb66 upstream.

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 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Validate cpu early in perf_event_alloc()

2011-02-17T23:14:48+00:00

commit 66832eb4baaaa9abe4c993ddf9113a79e39b9915 upstream.

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 
LKML-Reference: <20110118161032.GC693@redhat.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

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

2011-02-17T23:14:47+00:00

commit 22a4ec729017ba613337a28f306f94ba5023fe2e upstream.

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 
LKML-Reference: <20110118161008.GB693@redhat.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Fix alloc_callchain_buffers()

2011-02-17T23:14:46+00:00

commit 88d4f0db7fa8785859c1d637f9aac210932b6216 upstream.

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 
LKML-Reference: <1295980851.3588.351.camel@edumazet-laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Fix off by one in perf_swevent_init()

2010-12-16T10:14:31+00:00

The perf_swevent_enabled[] array has PERF_COUNT_SW_MAX elements.

Signed-off-by: Dan Carpenter 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <20101024195041.GT5985@bicker>
Signed-off-by: Ingo Molnar

perf: Fix duplicate events with multiple-pmu vs software events

2010-12-08T19:14:08+00:00

Because the multi-pmu bits can share contexts between struct pmu
instances we could get duplicate events by iterating the pmu list.

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

perf: Fix the software context switch counter

2010-11-26T14:00:59+00:00

Stephane noticed that because the perf_sw_event() call is inside the
perf_event_task_sched_out() call it won't get called unless we
have a per-task counter.

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

perf: Fix inherit vs. context rotation bug

2010-11-26T14:00:56+00:00

It was found that sometimes children of tasks with inherited events had
one extra event. Eventually it turned out to be due to the list rotation
no being exclusive with the list iteration in the inheritance code.

Cure this by temporarily disabling the rotation while we inherit the events.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Cc: 
Signed-off-by: Ingo Molnar

perf: Fix owner-list vs exit

2010-11-18T12:18:46+00:00

Oleg noticed that a perf-fd keeping a reference on the creating task
leads to a few funny side effects.

There's two different aspects to this:

  - kernel based perf-events, these should not take out
    a reference on the creating task and appear on the task's
    event list since they're not bound to fds nor visible
    to userspace.

  - fork() and pthread_create(), these can lead to the creating
    task dying (and thus the task's event-list becomming useless)
    but keeping the list and ref alive until the event is closed.

Combined they lead to malfunction of the ptrace hw_tracepoints.

Cure this by not considering kernel based perf_events for the
owner-list and destroying the owner-list when the owner dies.

Reported-by: Oleg Nesterov 
Signed-off-by: Peter Zijlstra 
Acked-by: Oleg Nesterov 
LKML-Reference: <1289576883.2084.286.camel@laptop>
Signed-off-by: Ingo Molnar

Merge branch 'perf/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into perf/urgent

2010-11-18T09:37:51+00:00