linux-kernel - Re: [git pull] drm fixes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1006081953060.4506@i5.linux-foundation.org>
Date:	Tue, 8 Jun 2010 20:16:06 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm fixes

On Wed, 9 Jun 2010, Dave Airlie wrote:
> 
> So this pull does try and fix some problems in a feature we added in -rc1, 
> radeon power management, its either the voltage fixes in here, or just 
> remove voltage stuff completely, but since it works in some cases that 
> would be a regression in itself.

I'm going to take this and hope _really_ hard that it works - since the 
number of current radeon reports seems to mean that I pretty much have to 
take it.

But I want to protest that "regression in itself" statement. We do _not_ 
count new code that needs to be undone as a "regression". Otherwise we 
would be in the situation where "fix one bug, introduce another" could not 
be reverted, because reverting it would "regress" the bug that got fixed.

And in fact that's exactly _why_ we introduced the strict regression 
fixing policy, because we used to have these "one step forward, unknown 
number of steps back" dances especially in power management and ACPI. A 
patch fixed something, but broke some other machine, and people claimed it 
fixed more than it broke (which is an impossible statement to really 
quantify).

So new code simply doesn't matter. Reverting new code is never a 
regression, even if that new code made something work. It's _old_ working 
setups that matter from the regression standpoint.

		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/