From: Mark Rutland <mark.rutland@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"vincent.weaver@maine.edu" <vincent.weaver@maine.edu>,
"eranian@gmail.com" <eranian@gmail.com>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC][PATCH 1/3] perf: Tighten (and fix) the grouping condition
Date: Fri, 23 Jan 2015 15:02:12 +0000 [thread overview]
Message-ID: <20150123150211.GA6091@leverpostej> (raw)
In-Reply-To: <20150123125834.090683288@infradead.org>
On Fri, Jan 23, 2015 at 12:52:00PM +0000, Peter Zijlstra wrote:
> The fix from 9fc81d87420d ("perf: Fix events installation during
> moving group") was incomplete in that it failed to recognise that
> creating a group with events for different CPUs is semantically
> broken -- they cannot be co-scheduled.
>
> Furthermore, it leads to real breakage where, when we create an event
> for CPU Y and then migrate it to form a group on CPU X, the code gets
> confused where the counter is programmed -- triggered by the fuzzer.
>
> Fix this by tightening the rules for creating groups. Only allow
> grouping of counters that can be co-scheduled in the same context.
> This means for the same task and/or the same cpu.
It seems this would still allow you to group CPU-affine software and
uncore events, which also doesn't make sense: the software events will
count on a single CPU while the uncore events aren't really CPU-affine.
Which isn't anything against this patch, but probably something we
should tighten up too.
>
> Fixes: 9fc81d87420d ("perf: Fix events installation during moving group")
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> include/linux/perf_event.h | 6 ------
> kernel/events/core.c | 15 +++++++++++++--
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -450,11 +450,6 @@ struct perf_event {
> #endif /* CONFIG_PERF_EVENTS */
> };
>
> -enum perf_event_context_type {
> - task_context,
> - cpu_context,
> -};
> -
> /**
> * struct perf_event_context - event context structure
> *
> @@ -462,7 +457,6 @@ enum perf_event_context_type {
> */
> struct perf_event_context {
> struct pmu *pmu;
> - enum perf_event_context_type type;
> /*
> * Protect the states of the events in the list,
> * nr_active, and the list:
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6846,7 +6846,6 @@ int perf_pmu_register(struct pmu *pmu, c
> __perf_event_init_context(&cpuctx->ctx);
> lockdep_set_class(&cpuctx->ctx.mutex, &cpuctx_mutex);
> lockdep_set_class(&cpuctx->ctx.lock, &cpuctx_lock);
> - cpuctx->ctx.type = cpu_context;
> cpuctx->ctx.pmu = pmu;
>
> __perf_cpu_hrtimer_init(cpuctx, cpu);
> @@ -7493,7 +7492,19 @@ SYSCALL_DEFINE5(perf_event_open,
> * task or CPU context:
> */
> if (move_group) {
> - if (group_leader->ctx->type != ctx->type)
> + /*
> + * Make sure we're both on the same task, or both
> + * per-cpu events.
> + */
> + if (group_leader->ctx->task != ctx->task)
> + goto err_context;
> +
Up to this point, this looks very similar to what I tried previously
[1], where we eventually figured out [2] that this raced with the
context switch optimisation. I never got around to fixing that race.
I'll try and get my head around that again. I'm not sure if that's still
a problem, and from a quick look at this series it's not clear that it
would be fixed if it is a problem.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/2/10/937
[2] https://lkml.org/lkml/2014/2/27/834
next prev parent reply other threads:[~2015-01-23 15:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 12:51 [RFC][PATCH 0/3] perf fixes Peter Zijlstra
2015-01-23 12:52 ` [RFC][PATCH 1/3] perf: Tighten (and fix) the grouping condition Peter Zijlstra
2015-01-23 15:02 ` Mark Rutland [this message]
2015-01-23 15:07 ` Peter Zijlstra
2015-01-23 15:22 ` Mark Rutland
2015-02-04 12:59 ` Peter Zijlstra
2015-01-28 14:30 ` [tip:perf/urgent] " tip-bot for Peter Zijlstra
2015-01-23 12:52 ` [RFC][PATCH 2/3] perf: Add a bit of paranoia Peter Zijlstra
2015-01-26 16:26 ` Peter Zijlstra
2015-01-27 21:28 ` Vince Weaver
2015-01-29 2:16 ` Vince Weaver
2015-01-29 7:51 ` Jiri Olsa
2015-01-29 13:44 ` Peter Zijlstra
2015-02-04 14:39 ` [tip:perf/core] perf: Fix put_event() ctx lock tip-bot for Peter Zijlstra
2015-01-29 14:47 ` [RFC][PATCH 2/3] perf: Add a bit of paranoia Peter Zijlstra
2015-02-02 6:33 ` Vince Weaver
2015-02-02 15:42 ` Peter Zijlstra
2015-02-02 17:32 ` Peter Zijlstra
2015-02-04 14:51 ` Jiri Olsa
2015-02-04 16:33 ` Peter Zijlstra
2015-02-04 16:43 ` Peter Zijlstra
2015-02-04 14:39 ` [tip:perf/core] perf: Fix move_group() order tip-bot for Peter Zijlstra (Intel)
2015-02-04 14:39 ` [tip:perf/core] perf: Add a bit of paranoia tip-bot for Peter Zijlstra
2015-01-23 12:52 ` [RFC][PATCH 3/3] perf: Fix event->ctx locking Peter Zijlstra
2015-02-04 14:39 ` [tip:perf/core] " tip-bot for Peter Zijlstra
2015-01-26 14:30 ` [RFC][PATCH 0/3] perf fixes Vince Weaver
2015-01-26 18:03 ` Vince Weaver
2015-01-26 18:34 ` Jiri Olsa
2015-01-26 18:52 ` Vince Weaver
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=20150123150211.GA6091@leverpostej \
--to=mark.rutland@arm.com \
--cc=eranian@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.