All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>
Subject: Re: perf: fuzzer causes lockup in x86_pmu_event_init()
Date: Wed, 25 Feb 2015 16:16:39 +0100	[thread overview]
Message-ID: <20150225151639.GL5029@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <alpine.DEB.2.11.1502232239080.31336@vincent-weaver-1.umelst.maine.edu>

On Mon, Feb 23, 2015 at 10:56:10PM -0500, Vince Weaver wrote:
> On Tue, 17 Feb 2015, Vince Weaver wrote:
> 
> > This is on a Haswell machine, current git as of this past Friday.
> > 
> > I let the perf_fuzzer run and it took 4 days to find this.
> > Sadly it doesn't seem to be reproducible so I am not sure
> > how it exactly got into this state.
> 
> I have hit this on another machine, my core2 machine (after 10 days of 
> fuzzing).  So this seems to be a real issue although hard to hit.
> 
> The problem seems to map to 
> 	arch/x86/kernel/cpu/perf_event.c:824
> 
> It is stuck forever in this loop in collect_events()
> 
>         list_for_each_entry(event, &leader->sibling_list, group_entry) {
>                 if (!is_x86_event(event) ||
>                     event->state <= PERF_EVENT_STATE_OFF)
>                         continue;
> 
>                 if (n >= max_count)
>                         return -EINVAL;
> 
>                 cpuc->event_list[n] = event;
>                 n++;
>         }
> 

> [884044.228001] RIP: 0010:[<ffffffff810138a8>]  [<ffffffff810138a8>] x86_pmu_event_init+0x138/0x31d

> [884044.228001] Call Trace:
> [884044.228001]  [<ffffffff810cec1b>] perf_try_init_event+0x25/0x47
> [884044.228001]  [<ffffffff810d488d>] perf_init_event+0x93/0xca
> [884044.228001]  [<ffffffff810d4b5f>] perf_event_alloc+0x29b/0x32d
> [884044.228001]  [<ffffffff810d5008>] SYSC_perf_event_open+0x417/0x89c
> [884044.228001]  [<ffffffff810d57fe>] SyS_perf_event_open+0x9/0xb

That smells like a corrupted sibling_list, I see no other way for that
loop to not end.

It occurs to me that that list iteration is entirely unserialized, we
should be holding a ctx lock or mutex, but we do not.

Now IIRC the perf fuzzer is single threaded, so it would not actually
trigger the most horrible cases here; but this does smell bad.

Does something like the below make sense and/or help? Jolsa?

---
 kernel/events/core.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index af924bc38121..763e7c02e796 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7049,12 +7049,23 @@ EXPORT_SYMBOL_GPL(perf_pmu_unregister);
 
 static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
 {
+	struct perf_event_context *ctx = NULL;
 	int ret;
 
 	if (!try_module_get(pmu->module))
 		return -ENODEV;
+
+	if (event->group_leader != event) {
+		ctx = perf_event_ctx_lock(event->group_leader);
+		BUG_ON(!ctx);
+	}
+
 	event->pmu = pmu;
 	ret = pmu->event_init(event);
+
+	if (ctx)
+		perf_event_ctx_unlock(event->group_leader, ctx);
+
 	if (ret)
 		module_put(pmu->module);
 

  reply	other threads:[~2015-02-25 15:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 16:17 perf: fuzzer causes lockup in x86_pmu_event_init() Vince Weaver
2015-02-24  3:56 ` Vince Weaver
2015-02-25 15:16   ` Peter Zijlstra [this message]
2015-02-28 12:14     ` Jiri Olsa
2015-03-02 19:13       ` Vince Weaver
2015-03-04 10:32         ` Jiri Olsa
2015-03-17 13:55         ` Jiri Olsa
2015-03-17 14:11           ` Peter Zijlstra
2015-03-17 15:00           ` Vince Weaver
2015-03-17 14:10       ` Peter Zijlstra
2015-03-27 11:46     ` [tip:perf/core] perf: Fix racy group access tip-bot for Peter Zijlstra

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=20150225151639.GL5029@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.