linux-kernel - Re: 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 06:05:07 +0100
From:	Mike Galbraith <efault@....de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Jiri Slaby <jirislaby@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>, gregkh@...e.de,
	srostedt <srostedt@...hat.com>, a.p.zijlstra@...llo.nl,
	ghaskins@...ell.com, stable@...nel.org,
	stable-commits@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Patch "sched: Give CPU bound RT tasks preference" has been
 added to the 2.6.32-longterm tree

On Wed, 2011-02-16 at 15:29 +0100, Stefan Richter wrote:
> On Feb 16 Mike Galbraith wrote:
> > On Wed, 2011-02-16 at 09:55 +0100, Jiri Slaby wrote:
> > > On 02/16/2011 09:25 AM, Ingo Molnar wrote:
> > > > We try to concentrate on regression fixes though.
> > > 
> > > Hi, I cannot fully agree with this. The question is who are "we" here?
> > > If every packager using this stable tree is forced by users/customers to
> > > take it anyway, it's better to have it in stable.
> > > 
> > > It has several reasons:
> > > * It will have an eye of experts on them. Not that at distro providers
> > > there are no experts, but the authors who are cced here know definitely
> > > the code better.
> > > * Not every packager has to duplicate others work.
> > > * The stable tree changes constantly. Managing hundreds of patches
> > > applied to a stable tree before kernels are being packaged is thus
> > > sometimes a hell. Reducing this number is a good thing(TM).
> > 
> > Fully agree on all fronts, but it's a hard call.  When I start auditing,
> > I sweat bullets.  I see piles of bug fixes, and piles of performance
> > enhancements, all of which are ever so tempting, all of which are worthy
> > of backport.. but humans _are_ buggy, so there is risk involved.
> 
> Jiri,
> if the desire is to improve performance of existing features (and maybe
> add this and that little feature that looks attractive), while at the same
> time you want
>   - experts to have looked at these improvements,
>   - packagers to avoid duplicate work,
>   - keep the number of local patches in check,
> then the solution is to /stay close enough to the mainline/.

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.

Just my opinion.  Oh, and critical eye is definitely good, that's why I
posted to stable after all ;-)

	-Mike

--
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/