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]

Date:	Tue, 16 Jul 2013 11:29:15 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	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>,
	Willy Tarreau <w@....eu>
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

On Tue, Jul 16, 2013 at 10:58 AM, Luck, Tony <tony.luck@...el.com> wrote:
>
> Linux testing is (realistically) done by inflicting changes on gradually wider
> sets of end users.

However, one thing that people should keep in mind that the testing is
often self-selecting.

This is particularly true for "obvious fixes". The _only_ early
testers tend to be the people who saw the problem in the first place,
and the fact that a patch fixes it for *them* can be very very
misleading during that early testing phase. Because obviously that
self-selecting group of people were somehow fundamentally different
from the rest of the world, and different in a way that was very
particular to the problem.

This is in particular what we've often seen with things like the PCI
layer resource management, and what we used to see a lot back in the
bad old days wrt suspend/resume. And it's why I'd really prefer for
even "obvious" patches to not be backported all that aggressively
unless there is very strong pressure. It's very much why that stable
documentation talks about "critical" issues.

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).

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.

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