linux-kernel - Re: [ 00/78] 3.3.2-stable review

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, 12 Apr 2012 20:40:58 +0200
From:	Willy Tarreau <w@....eu>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	Sujith Manoharan <c_manoha@....qualcomm.com>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [ 00/78] 3.3.2-stable review

On Thu, Apr 12, 2012 at 07:49:34PM +0300, Felipe Contreras wrote:
> On Thu, Apr 12, 2012 at 5:46 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > A revert is the same as a patch.  It needs to be in Linus's tree before
> > I can add it to the stable releases.
> 
> Right, because otherwise people's systems would actually work.
> 
> But hey, as I said, following rules is more important, regardless of
> what the rules are, and why they are there. The rules that actually
> triggered this issue in v3.3.1, as this is not in v3.3.
> 
> You could just accept that the patch should have never landed in
> v3.3.1 in the first place, but it's much easier to arbitrarily keep
> stacking patches without thinking too much about them.
> 
> I guess I'll better use Linus's releases for now and go to v3.3.

Felipe, you're unfair to Greg. You're saying this because you don't know
what it's like to be on the side of the guy who has to decide whether
to apply a patch or not, which basically means whether to risk breaking
systems or to leave broken systems as they are.

Most stable users will switch from a stable version to another one
in a next release, and these users do not want any regression. This
means that we absolutely don't want to risk that a stable version
has a fix that is missing from a newer version. Yes this is a crappy
and annoying process but it's the only way to ensure that fixes don't
get lost during an upgrade.

BTW, it works because if we're discussing this here, it's because
this final fix or revert appears to be missing from mainline. After
the discussion I'm sure it will be there.

Last point is that stable maintainers are not your slaves. If you know
how to patch your mainline kernel to apply a stable patch, you also
know how to apply the patch you're pointing to. It's quite easy and
many of us do that. *All* the kernels I'm using are stable + a few
local patches and I don't see where the problem is. So please be a bit
more constructive. Make your job by ensuring that the fix you want is
in mainline then pass the commit ID to Greg so that he can merge it in
next release. You'll feel relieved and everyone will be glad to benefit
from this fix.

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/