Re: Linux 2.6.32.34

[Frederic Weisbecker]

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.

OTOH the flow of patches that get stable tags is bigger now that people are
used to stable workflow. And checking every versions for all of them
may require quite some time. This implies one to keep these trees handy in
his filesystems and do careful checks, not even only build. That can be a bit
of a congestion point as more stable trees are maintained by the time. But
probably needed. Often it's simply a matter of doing a binary search to find
the first tree that starts the slice of the backport.
--
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/