linux-stable.git/kernel/perf_event.c, branch linux-2.6.34.y

perf: Fix tear-down of inherited group events

2013-01-16T21:45:07+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: Paul Gortmaker

perf_events: Fix races in group composition

2013-01-16T21:45:07+00:00

commit 8a49542c0554af7d0073aac0ee73ee65b807ef34 upstream.

Group siblings don't pin each-other or the parent, so when we destroy
events we must make sure to clean up all cross referencing pointers.

In particular, for destruction of a group leader we must be able to
find all its siblings and remove their reference to it.

This means that detaching an event from its context must not detach it
from the group, otherwise we can end up failing to clear all pointers.

Solve this by clearly separating the attachment to a context and
attachment to a group, and keep the group composed until we destroy
the events.

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

perf: overflow/perf_count_sw_cpu_clock crashes recent kernels

2012-08-17T19:35:00+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 
[PG: backport from 2.6.32 queue, see https://lkml.org/lkml/2011/8/3/125 ]
Signed-off-by: Paul Gortmaker

perf: Better fit max unprivileged mlock pages for tools needs

2012-03-14T14:56:50+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: Paul Gortmaker

fix mis-applied upstream commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318

2010-08-02T17:29:20+00:00

For some reason one of the changes to sys_perf_event_open() got
mis-applied, thus breaking (at least) error handling paths (pointed
out by means of a compiler warning).

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

perf_events: Fix races and clean up perf_event and perf_mmap_data interaction

2010-07-05T18:22:53+00:00

commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318 upstream.

In order to move toward separate buffer objects, rework the whole
perf_mmap_data construct to be a more self-sufficient entity, one
with its own lifetime rules.

This greatly sanitizes the whole output redirection code, which
was riddled with bugs and races.

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

perf: Fix signed comparison in perf_adjust_period()

2010-07-05T18:22:51+00:00

commit f6ab91add6355e231e1c47897027b2a6ee4fa268 upstream.

Frederic reported that frequency driven swevents didn't work properly
and even caused a division-by-zero error.

It turns out there are two bugs, the division-by-zero comes from a
failure to deal with that in perf_calculate_period().

The other was more interesting and turned out to be a wrong comparison
in perf_adjust_period(). The comparison was between an s64 and u64 and
got implicitly converted to an unsigned comparison. The problem is
that period_left is typically < 0, so it ended up being always true.

Cure this by making the local period variables s64.

Reported-by: Frederic Weisbecker 
Tested-by: Frederic Weisbecker 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
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:21:55+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 exit() vs event-groups

2010-07-05T18:21:55+00:00

commit 96c21a460a37880abfbc8445d5b098dbab958a29 upstream.

Corey reported that the value scale times of group siblings are not
updated when the monitored task dies.

The problem appears to be that we only update the group leader's
time values, fix it by updating the whole group.

Reported-by: Corey Ashford 
Signed-off-by: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Mike Galbraith 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
LKML-Reference: <1273588935.1810.6.camel@laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Fix exit() vs PERF_FORMAT_GROUP

2010-07-05T18:21:55+00:00

commit 050735b08ca8a016bbace4445fa025b88fee770b upstream.

Both Stephane and Corey reported that PERF_FORMAT_GROUP didn't
work as expected if the task the counters were attached to quit
before the read() call.

The cause is that we unconditionally destroy the grouping when
we remove counters from their context. Fix this by splitting off
the group destroy from the list removal such that
perf_event_remove_from_context() does not do this and change
perf_event_release() to do so.

Reported-by: Corey Ashford 
Reported-by: Stephane Eranian 
Signed-off-by: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
Cc: Paul Mackerras 
LKML-Reference: <1273571513.5605.3527.camel@twins>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman