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:	Fri, 13 Apr 2012 00:20:20 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.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 10:05 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Apr 12, 2012 at 9:49 AM, Felipe Contreras
> <felipe.contreras@...il.com> 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.
>
> There are rules for a damn good reason.
>
> The rule for -stable is that the changes *have* to be in upstream, for
> a very simple reason: otherwise bugs get re-introduced.
>
> If -stable starts revertign things that aren't reverted up-stream,
> what do you think happens to the *next* kernel version?

Which is why nobody is trying to change the rules regarding that.

And your same argument applies to the all the thousands of commits on
the next kernel version; what would happen on the next kernel version?

The relevant patch, like the thousands of patches in v3.4-rc*, did not
exist in v3.3, so if you add one on v3.3.1, and remove it on v3.3.2
would be *exactly* the same as if you had not added it at all to the
stable series.

> I don't think you realize how well kernel development has worked over
> the last few years. And the stable rules are part of it.

I do understand how well the development works, which is why I often
use it as an example and guideline, but that doesn't mean it's
perfect.

> So stop complaining. Reverts really *are* just patches, Greg is 100%
> right, and you are simply wrong.

I could argue in favor of exceptions, but I don't think you realize
the fact that this change does not affect your tree *at all*. Adding
and removing a patch in the stable tree is a no-op.

> And the revert is now apparently in John's tree, and will make it to
> David and then me shortly. It will get reverted in stable too once
> that happens. In the meantime, your complaints are  to Greg only shows
> that you don't understand why the rules exist, and the fact that you
> *continue* to complain just makes you look stupid.

Is that going to happen before Friday? If not, then v3.3.2 will still
be broken *for no reason*.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ