linux-kernel - Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch out of staging."

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100204205734.GB19050@elte.hu>
Date:	Thu, 4 Feb 2010 21:57:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Dave Airlie <airlied@...ux.ie>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.sf.net
Subject: Re: hung bootup with "drm/radeon/kms: move radeon KMS on/off switch
 out of staging."

* Jesse Barnes <jbarnes@...tuousgeek.org> wrote:

[...]
> > That action might hang or crash his kernel, and if that user then 
> > reports:
> > 
> >   " 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. "
> > 
> > is this really the right kind of reply:
> > 
> >  " Since we moved it from drivers/staging/ to drivers/ this hang you
> > are seeing is technically not a regression, we might or might not fix
> > it. "
> > 
> > ?
> > 
> > I doubt the user would be overly enthusiastic about that kind of
> > reply ;-)
> 
> Whether or not it's a regression is mostly irrelevant, it's a real bug and 
> the radeon guys are working on fixing it. [...]

Fortunately it's being worked on.

I beg to differ with your argument about it not mattering whether a bug is 
categorized as a regression: Rafael's regression list is far more prominent 
and the bugs listed there get fixed with a high likelhood.

Note that there's clear evidence of that in this very thread: the hang bug 
was ignored as a "plain" DRM non-regression bugreport, _despite_ the prior 
scrutiny in the thread, up to the moment Linus pointed it out and turned it 
into a de-facto regression ...

There's also another purpose of categorizing bugs as regressions: tester 
timeliness. We tend to treat bugs as 'plain bugs' when they are reported too 
late after a few kernel releases of the bug having been in the wild. We do 
this to encourage testers to test earlier -rc's as well, as there's a real 
tangible benefit of the 'we dont do regressions' policy: bugs get fixed and 
testers feel involved, and it's also the stage were we _can_ fix bugs with a 
lower cost to all parties involved.

But what 'timeliness of testing' can there be if new features are added in a 
late -rc and bugs are explicitly categorized as 'not a regression'?

	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/