Re: Linux 2.6.32.34

From: Greg KH
Date: Thu Mar 24 2011 - 10:58:33 EST


On Thu, Mar 24, 2011 at 12:49:56PM +0100, Frederic Weisbecker wrote:
> 2011/3/24 Ingo Molnar <mingo@xxxxxxx>:
> >
> > * Greg KH <gregkh@xxxxxxx> wrote:
> >
> >> On Thu, Mar 24, 2011 at 01:18:17AM +0100, Jiri Slaby wrote:
> >> > On 03/23/2011 09:34 PM, Greg KH wrote:
> >> > > --- a/kernel/perf_event.c
> >> > > +++ b/kernel/perf_event.c
> >> > > @@ -4167,6 +4167,8 @@ static void tp_perf_event_destroy(struct perf_event *event)
> >> > >
> >> > > Âstatic const struct pmu *tp_perf_event_init(struct perf_event *event)
> >> > > Â{
> >> > > + if (event->hw.state & PERF_HES_STOPPED)
> >> > > + Â Â Â Â return 0;
> >> > > Â /*
> >> > > Â Â* Raw tracepoint data is a severe data leak, only allow root to
> >> > > Â Â* have these.
> >> >
> >> > This causes build to fail:
> >> > /usr/src/packages/BUILD/kernel-vanilla-2.6.32.34/linux-2.6.32/kernel/perf_event.c:
> >> > Inâfunctionâ'tp_perf_event_init':
> >> > /usr/src/packages/BUILD/kernel-vanilla-2.6.32.34/linux-2.6.32/kernel/perf_event.c:4170:
> >> > error:â'structâhw_perf_event'âhasânoâmemberânamedâ'state'
> >> > /usr/src/packages/BUILD/kernel-vanilla-2.6.32.34/linux-2.6.32/kernel/perf_event.c:4170:
> >> > error:â'PERF_HES_STOPPED'âundeclaredâ(firstâuseâinâthisâfunction)
> >> > /usr/src/packages/BUILD/kernel-vanilla-2.6.32.34/linux-2.6.32/kernel/perf_event.c:4170:
> >> > error:â(Eachâundeclaredâidentifierâisâreportedâonlyâonce
> >> > /usr/src/packages/BUILD/kernel-vanilla-2.6.32.34/linux-2.6.32/kernel/perf_event.c:4170:
> >> > error:âforâeachâfunctionâitâappearsâin.)
> >> >
> >> >
> >> > The source:
> >> > commit 6f197b73304b3bd3d5a43b931383a5331d6b2987
> >> > Author: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> >> > Date: Â Mon Mar 7 21:27:09 2011 +0100
> >> >
> >> > Â Â perf: Handle stopped state with tracepoints
> >> >
> >> > Â Â commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream.
> >> >
> >> > Â Â We toggle the state from start and stop callbacks but actually
> >> > Â Â don't check it when the event triggers. Do it so that
> >> > Â Â these callbacks actually work.
> >>
> >> Ick, I don't know why it builds fine here. ÂFederic, should I just drop
> >> this patch for the .32 tree?
> >
> > Yes, please drop it.
> >
> > Thanks,
> >
> > Â Â Â ÂIngo
> >
>
> Yeah sorry for this. The patch actually only applies starting from 2.6.37
> Naked stable@xxxxxxxxxx tags (which I confess I use too) without version slice
> are sometimes creepy because they can cause such patches that may physically
> apply but not logically. And that's not the first time. Sometimes it's
> even worse when
> it applies and builds but fails on runtime because the old code flow
> was different. I
> remember a similar case with an old breakpoint patch that needed a
> different backport
> version in .33, I was lucky enough to anticipate but a naked stable
> tag would have broken.

No problem, this was my fault in that my build tests didn't catch it.
Which is odd, I should be using the same .config that Jiri was, I need
to see what I did wrong here...

I'll go revert it and put out a new version now.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/