linux-kernel - Re: [stable] Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Feb 2011 07:22:28 +0100
From:	Willy Tarreau <w@....eu>
To:	Mike Galbraith <efault@....de>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Jiri Slaby <jirislaby@...il.com>, gregkh@...e.de,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	srostedt <srostedt@...hat.com>, stable-commits@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>, ghaskins@...ell.com,
	stable@...nel.org, a.p.zijlstra@...llo.nl
Subject: Re: [stable] Patch "sched: Give CPU bound RT tasks preference" has been added to the 2.6.32-longterm tree

Hi Mike,

On Thu, Feb 17, 2011 at 06:05:07AM +0100, Mike Galbraith wrote:
> That's the intent of pushing more than _purely_ critical bugfixes, get a
> bit closer.  Enterprise can't move as fast as mainline, not even close,
> that's a given.  Stable problem get griped about though, so there's no
> choice but to take some risk.  The tricky bit is how much, and how you
> go about it.
> 
> People are fixing this and that in their enterprise kernels privately
> every day.  The only difference between that, and pushing baked fixes
> back is that pushing to stable is visible.  I strongly suspect that
> there are just tons of mainline backports sitting in each and every
> enterprise tree in existence.  They could have been pushed to stable,
> with _less_ stability risk, due to the higher visibility.

I can confirm that my local 2.6.27 tree has had a quite number of sched
updates that were posted by Ingo, Peter or You in the last two years,
and I'll definitely be considering your work for future updates. However
we must be very careful about what we include in -stable. Its primary
purpose precisely is to let every user upgrade without checking what was
merged because we are responsible for ensuring there is no regression. I
would say it's already a bit late in the 2.6.32 cycle for that but we're
in the first half of its lifecycle and it has a lot of users, so that
would still benefit a lot of people. Let's just hope it will not break
any workload (eg: double the time it takes for a specific task) otherwise
-stable and -longterm will lose some trust among enterprise users.

Ideally we should just make a stable release with just enhancements
from time to time, without important fixes so that people can revert
to the previous one and alert us in case of trouble. But my feeling
is that the current version more or less matches that goal, I don't
remember having seen anything really critical in it that can't be
reverted in case of trouble.

So let's have it, tell users to report any issue and move on :-)

Regards,
Willy

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