[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130807223550.GB17118@mudshark.cambridge.arm.com>
Date: Wed, 7 Aug 2013 23:35:50 +0100
From: Will Deacon <will.deacon@....com>
To: Vince Weaver <vincent.weaver@...ne.edu>
Cc: Mark Rutland <Mark.Rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
"trinity@...r.kernel.org" <trinity@...r.kernel.org>
Subject: Re: perf,arm -- oops in validate_event
On Wed, Aug 07, 2013 at 04:30:33PM +0100, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Vince Weaver wrote:
> > On Wed, 7 Aug 2013, Will Deacon wrote:
> > > 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.
Ok, thanks for testing, I'll send the fix to rmk with a CC for stable.
As for future work, we want to support multiple HW PMUs on ARM yet restrict
event groups to accept events targetting the same HW PMU. If we allow groups
to have a software event as a leader, yet still accept HW events, then this
check becomes a real pain because we essentially have to stash the PMU for
the first HW event added to the group.
I think I'd rather fail validation when adding a HW event to a group with a
SW event as a group leader.
PeterZ: any thoughts? This sort of stuff feels like it should really belong
in core code...
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists