linux-kernel - Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

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: <20130716184848.GI15902@1wt.eu>
Date:	Tue, 16 Jul 2013 20:48:48 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.de>,
	David Lang <david@...g.hm>,
	"ksummit-2013-discuss@...ts.linux-foundation.org" 
	<ksummit-2013-discuss@...ts.linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
> There have been tons of obvious patches that turned out to simply be
> wrong - often for very non-obvious reasons. Even when they are small.
> And the problems seldom get caught in early testing, often exactly
> because of this self-selecting property of testers (and test*ing* -
> when you fix a particular behavior, you tend to test the behavior
> you're trying to fix, you don't test the other cases that the patch
> wasn't about).

I can't agree more, I know it's one of my defaults. I don't count the
number of bugs I have introduced in Haproxy while fixing a bug, and I
know this and care a lot about this. Still shit happens. And I'm sure
I'm not the only one out there !

> Anyway, the point I'm making is that Q&A is limited and often even
> actively misleading ("Hey, I have three tested-by's, so it must be
> fine"), and we might actually want to have a new class of
> "non-critical patch that might be worth backporting to stable, but
> only do so after it's been in a release for some time". Because while
> it might be an "obvious" fix, maybe it's not critical enough that it
> needs to be backported _now_ - maybe it could wait a month or two, and
> get wider testing.

That's what was discussed earlier in this thread, something like not
merging into stable before current kernel is released plus maybe one
.1 stable version to ensure that we've got some bug reports. That
would mean something like "don't backport this before 3.12.1 has
been released" for example. The tag could simply be "Not-Before".

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/