On Wed, Aug 07, 2013 at 02:00:27PM +0100, Will Deacon wrote: > On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote: > > On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote: > > > But we already check `event->pmu != leader_pmu' in validate_event, so we > > > shouldn't get anywhere nearer calling get_event_idx in the case you > > > describe. It sounds more like we have an inconsistency with one of the > > > events. > > > > Note in my example that the software event was the group leader (so in > > fact we'd *only* be checking those events which we can't actually > > handle...). > > > > I was also under the impression that in the case of mixed hardware and > > software events, a hardware event must be the group leader. That > > doesn't seem to be the case. If a hardware event is added to a software > > group, the group is moved to hardware context but the original software > > event stays as the group leader. > > Ok, so the following quick hack below should solve the issue (can you confirm > it please, since I don't have access to any hardware atm?) It works for me when running Vince's test case. Tested-by: Mark Rutland <mark.rutland@xxxxxxx> > > We should revisit this for 3.12 though, because I'm not sure that our > validation code even does the right thing when there are multiple PMUs > involved. Certainly. I suspect we're not alone there. Thanks, Mark. > > Will > > --->8 > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c > index d9f5cd4..0500f10b 100644 > --- a/arch/arm/kernel/perf_event.c > +++ b/arch/arm/kernel/perf_event.c > @@ -253,6 +253,9 @@ validate_event(struct pmu_hw_events *hw_events, > struct arm_pmu *armpmu = to_arm_pmu(event->pmu); > struct pmu *leader_pmu = event->group_leader->pmu; > > + if (is_software_event(event)) > + return 1; > + > if (event->pmu != leader_pmu || event->state < PERF_EVENT_STATE_OFF) > return 1; -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
