All of lore.kernel.org
 help / color / mirror / Atom feed
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:22:57 +0000	[thread overview]
Message-ID: <20150123152257.GB6091@leverpostej> (raw)
In-Reply-To: <20150123150716.GN2896@worktop.programming.kicks-ass.net>

On Fri, Jan 23, 2015 at 03:07:16PM +0000, Peter Zijlstra wrote:
> On Fri, Jan 23, 2015 at 03:02:12PM +0000, Mark Rutland wrote:
> > 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.
> 
> Indeed, that would need a wee bit of extra infrastructure though; as we
> cannot currently distinguish between regular cpuctx and uncore like
> things.

Isn't the event->pmu->task_ctx_nr sufficient, as with how we identify
software events?

Or am I making some completely bogus assumptions in the diff below?

Mark.

---->8----
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 664de5a..7b945d5 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -657,6 +657,15 @@ static inline int is_software_event(struct perf_event *event)
 	return event->pmu->task_ctx_nr == perf_sw_context;
 }
 
+/*
+ * Return 1 for an event which is associated with neither a particular
+ * CPU nor a particular task.
+ */
+static inline int is_system_event(struct perf_event *event)
+{
+	return event->pmu->task_ctx_nr == perf_invalid_context;
+}
+
 extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX];
 
 extern void __perf_sw_event(u32, u64, struct pt_regs *, u64);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2cb857d..50c42b6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7525,6 +7525,18 @@ SYSCALL_DEFINE5(perf_event_open,
 	account_event(event);
 
 	/*
+	 * System-wide (A.K.A. "uncore") events cannot be associated with a
+	 * particular CPU, and hence cannot be associated with a particular
+	 * task either. It's non-sensical to group them with other event types,
+	 * which are CPU or task bound.
+	 */
+	if (group_leader &&
+		(is_system_event(event) != is_system_event(group_leader))) {
+		err = -EINVAL;
+		goto err_alloc;
+	}
+
+	/*
 	 * Special case software events and allow them to be part of
 	 * any hardware group.
 	 */


  reply	other threads:[~2015-01-23 15:23 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
2015-01-23 15:07     ` Peter Zijlstra
2015-01-23 15:22       ` Mark Rutland [this message]
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=20150123152257.GB6091@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.