On Thu, May 09, 2013 at 11:45:00AM +0200, Ingo Molnar wrote: > > * Stanislaw Gruszka <sgruszka@xxxxxxxxxx> wrote: > > > On Thu, May 09, 2013 at 11:03:50AM +0200, Ingo Molnar wrote: > > > > > > * Stanislaw Gruszka <sgruszka@xxxxxxxxxx> wrote: > > > > > > > > I think we need to get the author's of the patch, and the maintainers > > > > > involved, to agree that this all needs to be in the 3.9-stable tree. > > > > > > > > I planed to post backport of just commit 68aa8efcd1ab "sched: Avoid > > > > prev->stime underflow", which fix 3.8 -> 3.9 regression. But Lingzhu > > > > Xiang overtake me here with this 4 patches post. I considered this as > > > > fine, since 3.9 code will match upstream, but I did not think originally > > > > that those additional 3 patches are needed in -stable. They are fixes, > > > > but do not fix current regression. They fix regression introduced in > > > > 2007 or so. > > > > > > > > So I'll just post backort of 68aa8efcd1ab. > > > > > > I'd suggest also marking those additional 3 fixes for -stable. That should > > > make it all apply and work just fine - or are there other dependencies > > > that make that difficult? > > > > > > In general the closer -stable code is to current upstream code the better > > > - even if it means the application of 7 fixes here. It will make it (much) > > > easier to fix bugs if they are reported against -stable. > > > > Ok, so I'll post them then. It will require adding commit > > f792685006274a850e6cc0ea9ade275ccdfc90bc and it's revert, > > commit f3002134158092178be81339ec5a22ff80e6c308 upstream, > > but that's no issue at all. > > Yeah - as long as it does not pull in too many non-fix bits it should be > OK and should be (much) easier to handle than trying to create something > stable-only. > > Size of a fixes queue shouldn't be an issue as long it works and as long > as it's not excessive - this was a truly difficult problem and you did a > nice job of mapping it out and fixing it for good. 7 fixes is what it > took. I agree, I have no problem taking 7 fixes, as long as they match up with what is in Linus's tree. thanks, greg k-h -- 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