On 01/23/2014 01:17 AM, Ingo Molnar wrote:
> * John Stultz <john.stultz@xxxxxxxxxx> wrote:
>
>> Just wanted to send out a few timekeeping fixes that were merged
>> in 3.14 which are appropriate for -stable.
> No, they are not appropriate at all.
>
>> This queue backports the following fixes:
>> -----------------------------------------
>> f55c07607a38f84b5c7e6066ee1cfe433fa5643c timekeeping: Fix lost updates to tai adjustment
>> 5258d3f25c76f6ab86e9333abf97a55a877d3870 timekeeping: Fix potential lost pv notification of time change
>> 6fdda9a9c5db367130cf32df5d6618d08b89f46a timekeeping: Avoid possible deadlock from clock_was_set_delayed
>> 04005f6011e3b504cd4d791d9769f7cb9a3b2eae timekeeping: Fix CLOCK_TAI timer/nanosleep delays
>> 330a1617b0a6268d427aa5922c94d082b1d3e96d timekeeping: Fix missing timekeeping_update in suspend path
>> d5a1c7e3fc38d9c7d629e1e47f32f863acbdec3d rtc-cmos: Add an alarm disable quirk
> These patches should have had Cc: stable in them and should have gone
> through timers/urgent!
They did have Cc: stable in them.
I even did submit three of them to you for 3.13, with my concerns about
how late in the cycle it was:
https://lkml.org/lkml/2013/12/20/384
As I said there:
"
However, as I've been thinking about this a bit more, I'm a little
on the fence about sending these out this late in the -rc cycle. The
lockdep splat is new in 3.13 due to the seqlock lockdep enablement,
but the actual potential deadlock is not new.
Also, given its so close to the holiday week, it might be wise to push
off to 3.14 with these. Does that sound reasonable? If so please just
apply to tip/timers/core instead, and I'll send Thomas the rest of my
3.14 queue soon.
"
I got no reply (reasonably due to the impending holidays), and after
returning I sent them on for 3.14 for two reasons:
1) It was getting very late in the 3.13 cycle (I wasn't expecting 3.13
to go on past -rc7 - I was actually scared I would miss the 3.14 window,
since you were out on holiday).
2) None of these issues were 3.13 regressions. The lockdep splat about
the possible deadlock was new with the seqlock reporting, but the actual
issue (clock_was_set_delayed not actually being safe) goes back fairly
far. All of these changes have to be backported to 3.10 (which I'm now
testing), and some further to 3.4 and possibly earlier.
> Merging fixes in the merge window this way is absolutely unacceptable.
> If a fix is good enough for -stable then it's doubly good for
> timers/urgent.
>
> You sent me those changes as:
>
> [GIT PULL] Timekeeping changes for 3.14
>
> Nothing said that those were urgent fixes - if they had I'd have
> insisted on merging them earlier.
>
> You in fact said:
>
> > This includes a number of changes I had earlier proposed for 3.13,
> > but decided to defer due to it being so late in the 3.13 cycle.
>
> Deferring them for v3.13 means they are not eligible for -stable!
I'd argue these were non-urgent fixes that should still be backported to
-stable.
Maybe I'm causing more trouble here by trying to be helpful and apply,
test and submit these myself instead of just letting the stable
maintainers pick them up on their own. But I've got to do it for 3.10
and 3.4 since those patches don't backport cleanly, and there's a
oneline change that needs to be pulled out of a non-stable patch, so I
figured I'd do it for all of them.
> So this is a big process FAIL, don't do that.
My sense of the processes (please correct me here) are there are two sides:
* Fixes to regressions introduced during the current -rc series: These
clearly are urgent and should be merged
* Good fixes for issues that have been around for a long time: These
usually are queued for the next merge window, and then backported to -stable
I have a sense there a fair amount of grey area between these, where
there are bugs that are maybe a bit more severe but aren't strictly
regressions sometimes are reasonably merged early in the -rc cycle. And
this seems to depends on the severity of the issue and the maintainer's
sense of the risk of the fix.
The other lockdep splats discovered by the seqlock changes are examples
of this (the splats are new, but the issues have been around awhile, but
are clearly potentially very bad issues). That said, the actual issue
has been present for quite some time, so its not strictly a regression.
In contrast, even though it was discovered quite late, the ARM
sched_clock/lockdep hang I sent via Peter was clearly a 3.13-rc
regression and needed to go in before 3.13 (and just barely made it!).
My apologies for causing you grief here, it was not my intention. And
while I may have made a bad call here, I don't think it was very far
from the right choice.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html