From: Peter Zijlstra <peterz@infradead.org>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [perf] more perf_fuzzer memory corruption
Date: Fri, 18 Apr 2014 18:59:58 +0200 [thread overview]
Message-ID: <20140418165958.GQ13658@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20140418152314.GY11182@twins.programming.kicks-ass.net>
On Fri, Apr 18, 2014 at 05:23:14PM +0200, Peter Zijlstra wrote:
> OK, that's a good clue. That looks like we're freeing events that still
> are on the owner list, which would indicate we're freeing events that
> have a refcount.
>
> I added a WARN in free_event() to check the refcount, along with a
> number of false positives (through the perf_event_open() fail path) I do
> appear to be getting actual fails here.
>
> At least I can 'reproduce' this. Earlier attempts, even based on your
> .config only got me very mysterious lockups -- I suspect the corruption
> happens on a slightly different spot or so and completely messes up the
> machine.
The below should have only made the false positives go away, but my
machine has magically stopped going all funny on me. Could you give it a
go?
---
kernel/events/core.c | 73 +++++++++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 30 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f83a71a3e46d..f9d7b859395e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3231,8 +3231,11 @@ static void __free_event(struct perf_event *event)
call_rcu(&event->rcu_head, free_event_rcu);
}
-static void free_event(struct perf_event *event)
+
+static void _free_event(struct perf_event *event)
{
+ WARN_ON(atomic_long_read(&event->refcount));
+
irq_work_sync(&event->pending);
unaccount_event(event);
@@ -3259,45 +3262,28 @@ static void free_event(struct perf_event *event)
if (is_cgroup_event(event))
perf_detach_cgroup(event);
-
__free_event(event);
}
-int perf_event_release_kernel(struct perf_event *event)
-{
- struct perf_event_context *ctx = event->ctx;
-
- WARN_ON_ONCE(ctx->parent_ctx);
- /*
- * There are two ways this annotation is useful:
- *
- * 1) there is a lock recursion from perf_event_exit_task
- * see the comment there.
- *
- * 2) there is a lock-inversion with mmap_sem through
- * perf_event_read_group(), which takes faults while
- * holding ctx->mutex, however this is called after
- * the last filedesc died, so there is no possibility
- * to trigger the AB-BA case.
- */
- mutex_lock_nested(&ctx->mutex, SINGLE_DEPTH_NESTING);
- raw_spin_lock_irq(&ctx->lock);
- perf_group_detach(event);
- raw_spin_unlock_irq(&ctx->lock);
- perf_remove_from_context(event);
- mutex_unlock(&ctx->mutex);
-
- free_event(event);
+static void put_event(struct perf_event *event);
- return 0;
+static void free_event(struct perf_event *event)
+{
+ if (unlikely(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)) {
+ WARN(1, "unexpected event refcount: %ld\n",
+ atomic_long_read(&event->refcount));
+ put_event(event);
+ return;
+ }
+ _free_event(event);
}
-EXPORT_SYMBOL_GPL(perf_event_release_kernel);
/*
* Called when the last reference to the file is gone.
*/
static void put_event(struct perf_event *event)
{
+ struct perf_event_context *ctx = event->ctx;
struct task_struct *owner;
if (!atomic_long_dec_and_test(&event->refcount))
@@ -3336,9 +3322,36 @@ static void put_event(struct perf_event *event)
put_task_struct(owner);
}
- perf_event_release_kernel(event);
+ WARN_ON_ONCE(ctx->parent_ctx);
+ /*
+ * There are two ways this annotation is useful:
+ *
+ * 1) there is a lock recursion from perf_event_exit_task
+ * see the comment there.
+ *
+ * 2) there is a lock-inversion with mmap_sem through
+ * perf_event_read_group(), which takes faults while
+ * holding ctx->mutex, however this is called after
+ * the last filedesc died, so there is no possibility
+ * to trigger the AB-BA case.
+ */
+ mutex_lock_nested(&ctx->mutex, SINGLE_DEPTH_NESTING);
+ raw_spin_lock_irq(&ctx->lock);
+ perf_group_detach(event);
+ raw_spin_unlock_irq(&ctx->lock);
+ perf_remove_from_context(event);
+ mutex_unlock(&ctx->mutex);
+
+ _free_event(event);
}
+int perf_event_release_kernel(struct perf_event *event)
+{
+ put_event(event);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(perf_event_release_kernel);
+
static int perf_release(struct inode *inode, struct file *file)
{
put_event(file->private_data);
next prev parent reply other threads:[~2014-04-18 17:00 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 21:37 [perf] more perf_fuzzer memory corruption Vince Weaver
2014-04-15 21:49 ` Thomas Gleixner
2014-04-16 3:21 ` Vince Weaver
2014-04-16 4:18 ` Vince Weaver
2014-04-16 14:15 ` Peter Zijlstra
2014-04-16 17:30 ` Vince Weaver
2014-04-16 17:43 ` Vince Weaver
2014-04-16 17:47 ` Peter Zijlstra
2014-04-17 9:48 ` Ingo Molnar
2014-04-17 11:45 ` Peter Zijlstra
2014-04-17 14:22 ` Ingo Molnar
2014-04-17 14:42 ` Vince Weaver
2014-04-17 14:54 ` Peter Zijlstra
2014-04-17 15:35 ` Vince Weaver
2014-04-18 14:45 ` Vince Weaver
2014-04-18 14:51 ` Vince Weaver
2014-04-18 15:23 ` Peter Zijlstra
2014-04-18 16:59 ` Peter Zijlstra [this message]
2014-04-18 17:15 ` Peter Zijlstra
2014-04-23 20:58 ` Vince Weaver
2014-04-25 2:51 ` Vince Weaver
2014-04-28 14:21 ` Vince Weaver
2014-04-28 19:38 ` Vince Weaver
2014-04-29 9:46 ` Peter Zijlstra
2014-04-29 18:21 ` Vince Weaver
2014-04-29 19:01 ` Peter Zijlstra
2014-04-29 20:59 ` Vince Weaver
2014-04-30 18:44 ` Peter Zijlstra
2014-04-30 21:08 ` Vince Weaver
2014-04-30 22:51 ` Thomas Gleixner
2014-05-01 10:26 ` Peter Zijlstra
2014-05-01 11:50 ` Peter Zijlstra
2014-05-01 12:35 ` Thomas Gleixner
2014-05-01 13:12 ` Peter Zijlstra
2014-05-01 13:29 ` Thomas Gleixner
2014-05-01 13:22 ` Vince Weaver
2014-05-01 14:07 ` Vince Weaver
2014-05-01 14:27 ` Vince Weaver
2014-05-01 15:09 ` Peter Zijlstra
2014-05-01 15:50 ` Vince Weaver
2014-05-01 16:31 ` Thomas Gleixner
2014-05-01 17:18 ` Vince Weaver
2014-05-01 18:49 ` Vince Weaver
2014-05-01 21:32 ` Vince Weaver
2014-05-02 11:15 ` Peter Zijlstra
2014-05-02 15:42 ` Peter Zijlstra
2014-05-02 16:22 ` Vince Weaver
2014-05-02 16:22 ` Peter Zijlstra
2014-05-02 16:43 ` Vince Weaver
2014-05-02 17:27 ` Peter Zijlstra
2014-05-02 17:46 ` Vince Weaver
2014-05-02 19:12 ` Thomas Gleixner
2014-05-02 20:15 ` Vince Weaver
2014-05-02 20:45 ` Thomas Gleixner
2014-05-03 2:32 ` Vince Weaver
2014-05-03 3:02 ` Vince Weaver
2014-05-03 7:33 ` Peter Zijlstra
2014-05-05 9:31 ` Peter Zijlstra
2014-05-05 16:00 ` Vince Weaver
2014-05-05 17:10 ` Vince Weaver
2014-05-05 17:14 ` Peter Zijlstra
2014-05-05 18:47 ` Vince Weaver
2014-05-05 19:36 ` Peter Zijlstra
2014-05-05 19:51 ` Vince Weaver
2014-05-06 1:06 ` Vince Weaver
2014-05-06 16:57 ` Vince Weaver
2014-05-07 16:45 ` Peter Zijlstra
2014-05-08 10:40 ` [tip:perf/core] perf: Fix perf_event_init_context() tip-bot for Peter Zijlstra
2014-05-05 17:29 ` [perf] more perf_fuzzer memory corruption Ingo Molnar
2014-05-06 4:51 ` Vince Weaver
2014-05-06 17:06 ` Vince Weaver
2014-05-07 19:12 ` Ingo Molnar
2014-05-07 19:11 ` Ingo Molnar
2014-05-08 10:40 ` [tip:perf/core] perf: Fix race in removing an event tip-bot for Peter Zijlstra
2014-05-02 17:06 ` [perf] more perf_fuzzer memory corruption Vince Weaver
2014-05-02 17:04 ` Peter Zijlstra
2014-04-29 19:26 ` Steven Rostedt
2014-04-29 8:52 ` Peter Zijlstra
2014-04-29 18:11 ` Vince Weaver
2014-04-29 19:21 ` Steven Rostedt
2014-04-28 17:48 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140418165958.GQ13658@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vincent.weaver@maine.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).