Re: [PATCH 3.9-stable 1/4] sched: Lower chances of cputime scaling overflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]