On Wed, 7 Aug 2013, Vince Weaver wrote: > On Wed, 7 Aug 2013, Will Deacon wrote: > > > 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?) > > > > 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. > > > > --->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; > > this isn't enough. You can also trigger the oops by using > tracepoint or breakpoint events as group leaders in addition to software > events. I take that back, it turns out tracepoint and breakpoint both have task_ctx_nr set to perf_sw_context (althouth breakpoint has a comment saying this may change in the future). Let me compile and verify the fix. It may take some time for the compile to finish as it's not a very fast machine. Vince -- 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
