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: <20100204210559.GC19050@elte.hu>
Date:	Thu, 4 Feb 2010 22:05:59 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Alex Deucher <alexdeucher@...il.com>,
	Dave Airlie <airlied@...ux.ie>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch
 out of staging."


* Matthew Garrett <mjg59@...f.ucam.org> wrote:

> On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote:
> 
> >   " Hey, -rc7 just hung on me after enabling this new .config option it 
> >     offered for the radeon driver i am using, please add this to the list of 
> >     regressions. "
> 
> If the same configuration options hang on both an old kernel and a new 
> kernel, how is that in any plausible way a regression? What's regressed?

Regressions are not limited to 'same config' kernels, last i checked. If that 
has changed (or if i'm misunderstanding it) then it would be nice to hear a 
clarification about that from Linus.

The way i understand it is that there are narrow exceptions from the 
regression rules, such as completely new drivers for which there can be no 
prior expectation of stability by users. (but for even them we are generally 
on the safer side to list bugs in them as regressions as well - especially if 
we expect many users to enable it.)

AFAIK there's no exception for new sub-features of existing facilities or 
drivers, even if it's default-disabled.

This issue materially affects quite a few bugs i'm handling as a maintainer. 
Many of them are under default-off config options - most new aspects to 
existing code are introduced in such a way. It would remove quite a bit of 
urgent-workload from my workflow if i could strike them from Rafael's list 
and could deprioritize them as "plain bugs", to be fixed as time permits.

IMHO it would be rather counter-productive to kernel quality if we did that 
kind of regression-lawyering though.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ