linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover

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, 5 Apr 2011 07:42:14 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	Keith Packard <keithp@...thp.com>
Cc:	Tomas Winkler <tomasw@...il.com>,
	Pekka Enberg <penberg@...nel.org>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel@...ll.ch>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before
 KMS takeover

On Tue, Apr 5, 2011 at 3:30 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@...il.com> wrote:
>> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@...nel.org> wrote:
>> > Unfortunately I get a blank screen with after boot:
>> > Nacked-by: Pekka Enberg <penberg@...nel.org>
>
> But until you can tell me where it explodes on your system, we fix
> issues on several other machines...

NO.

Chris, you need to understand the issue of "NO REGRESSIONS".

It's a very simple rule: it DOES NOT MATTER ONE WHIT how many machines
you fix. You never ever regress. Patches that cause regressions are
reverted.

There are multiple reasons for that rule, but the basic one ends up
being very simple: you only _think_ you fix more machines than you
break. Why? Because the people who test out your patches are the
"active" people - and often predominantly the active people who have
problems. In contrast, the people for whom things already work aren't
even testing your patches in the first place. Then, six months later,
when they update to a new Fedora version, things suddenly don't work
for them, and it turns out that yes, you fixed ten active testers, but
you broke a thousand random people.

So even _one_ person saying "this is a regression" is a total blocker.
Really. It's that simple.

YOU NEVER EVER BREAK WORKING MACHINES.

Seriously. We had this for years in ACPI-land and with suspend/resume
with "one step forward, two steps back", and nobody ever knew if we
were doing any real progress at all, because machines that had working
suspend/resume one kernel version would be broken again the next.
There was no real pattern of improvement, there was just a random
pattern of "things get fixed on one machine, and break on another".

We introduced the "no regressions" rule, and things got seriously
better. Suddenly things started getting _reliably_ better.

The whole situation with i915 has been pretty damn random lately, and
you really really need to understand that this is simply not how it's
done. Your cavalier attitude ("but it fixes things for others") is
absolutely not acceptable.

Keith Cc'd, because that patch had better not show up in my tree.

                       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/