linux-kernel - Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

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:	Wed, 04 Feb 2009 20:45:47 -0800
From:	Eric Anholt <eric@...olt.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Norbert Preining <preining@...ic.at>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>
Subject: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Wed, 4 Feb 2009, Norbert Preining wrote:
> > > 
> > > The problem is that if you have a configuration under 2.6.28 without 
> > > CONFIG_FB and just call make oldconfig, or even make config and don't 
> > > know that you loose the DRM. And I was using make oldconfig (there is a 
> > > graphical config?? ;-))
> > 
> > Sure. It's inconvenient, no question about that. I asked the i915 people 
> > to look into not requiring CONFIG_FB, and I hope they will, but my point 
> > is that I don't think we can consider "small one-time inconvenience" to be 
> > a "regression".
> 
> if you mean that as a general principle, there's four very real downsides in 
> my opinion.
> 
> Firstly, we could have done better (and still can do better), via various 
> easy and non-intrusive measures:
> 
>    - We could add a runtime warning:
> 
>       for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB") 
>       that there's no DRM because CONFIG_FB is not selected and oldconfig 
>       loses the I915 setting silently - placed in a key DRM ioctl, would 
>       have gone a long way addressing the issue. Testers do notice kernel 
>       warnings that pop up when their X gets slow. (This approach might also 
>       have the added bonus of warning folks who enable the wrong driver for 
>       the hardware.)
> 
>    - Or we could add a more thoughtful Kconfig migration:
> 
>       Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
>       DRM_I915 as a non-interactive migration helper: if set, it 
>       auto-selects both FB and DRM_I915_FB.
> 
>       While CONFIG_FB is an interactive Kconfig option so a select can be 
>       dangerous to a correct dependency tree, it seems safe to do in this 
>       specific case because it seems to be a rather leaf entry with no 
>       dependencies.

I tried select FB.  It's the right thing to do.  It doesn't work.  I
posted to the mailing list two weeks ago about the insane dependency
chain that kbuild comes up with and fails on when we do this, and got
silence.

Believe me, I hate this inconvenience to users even more than each of
you do, because I get to deal with the reports.  But I haven't had the
time to sit down and figure out what drugs kbuild is on, or even how to
work around it (despite IRC help from a few other kernel guys).

The alternative I can see is to ifdef the code for something that will
be on by default and which stable userland will require in 6 months.
That seems wrong.

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)