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]

Message-ID: <20120414155733.GF19802@1wt.eu>
Date:	Sat, 14 Apr 2012 17:57:33 +0200
From:	Willy Tarreau <w@....eu>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Adrian Chadd <adrian@...ebsd.org>,
	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 Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote:
> So, the hypothetical patch that was dropped in the stable review queue
> yesterday has to be fixed in mainline too, just like the hypothetical
> patch that made it to stable and was found problematic today has to be
> fixed in mainline.

Patches are not always dropped from the stable queue if we know they're
causing issues, sometimes they're left pending in the queue. This is how
Greg is able to ping developers from time to time.

> Again, what makes a released patch undroppable?

Being applied, in other words, having a commit ID in the branch.

(...)
> Just by going through the stable review process the patch already
> received more eyes to make the bugs more shallow. There might be a lot
> of trees out there where people pick patches from mainline, and they
> don't *need* to follow the "upstream first" rule, by reviewing the
> patch, and maybe even testing it, and then reporting the problem, they
> are helping getting it fixed for v3.4.

They do what they want with their trees. I have a number of patches in my
trees that are not worth pushing to mainline and that's fine. However the
rule is that the official stable tree has to hold patches that come from
mainline.

> You don't *need* to keep the patch in the stable review queue, you
> don't *need* to make a stable release with it in order to ensure that
> it will fixed in mainline, the information about the patch problems is
> not lost.

It's lost since nobody cares once their kernel is fixed. For instance, I
have an issue with 3.0.x on my netbook which I haven't had time to bisect
(no resume from s2r). But 3.2 works. If I find that the issue was introduced
in any stable backport, we'll have to ensure that mainline has the fix,
because the bug might simply be hidden in 3.2 but still present. If we'd
just revert the fix from 3.0, what would motivate anyone to fix mainline
if it appears to work ?

> Seems to me you are abusing the 'stable' branch as a bug tracking
> system for certain patches for the next release.

The most reliable bug tracking system are the end users. They're the only
one who remind you to get their fix merged. And you did this yourself,
quite louder than the average I'd say, but it worked perfectly again.

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/