Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932931Ab3HGNAy (ORCPT ); Wed, 7 Aug 2013 09:00:54 -0400 Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:39596 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932738Ab3HGNAx (ORCPT ); Wed, 7 Aug 2013 09:00:53 -0400 Date: Wed, 7 Aug 2013 14:00:27 +0100 From: Will Deacon To: Mark Rutland Cc: Vince Weaver , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Ingo Molnar , Paul Mackerras , Arnaldo Carvalho de Melo , "trinity@vger.kernel.org" Subject: Re: perf,arm -- oops in validate_event Message-ID: <20130807130027.GA16474@mudshark.cambridge.arm.com> References: <20130806111932.GA25383@e106331-lin.cambridge.arm.com> <20130806115921.GA14798@mudshark.cambridge.arm.com> <20130806130815.GC25383@e106331-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130806130815.GC25383@e106331-lin.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1923 Lines: 46 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?) 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. 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/