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, 31 Mar 2010 23:47:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dave Airlie <airlied@...il.com>
Cc:	James Morris <jmorris@...ei.org>, "H. Peter Anvin" <hpa@...or.com>,
	Yinghai Lu <yinghai@...nel.org>, linux-kernel@...r.kernel.org,
	airlied@...ux.ie, Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: Config NO_BOOTMEM breaks my amd64 box


* Dave Airlie <airlied@...il.com> wrote:

> On Thu, Apr 1, 2010 at 4:59 AM, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * James Morris <jmorris@...ei.org> wrote:
> >
> >> On Tue, 30 Mar 2010, H. Peter Anvin wrote:
> >>
> >> > On 03/30/2010 09:49 PM, James Morris wrote:
> >> > >
> >> > > Please make NO_BOOTMEM default to n, at least for amd64, where I've found
> >> > > that it leads to all kinds of strange, undebuggable boot hangs and errors
> >> > > (with relatively current Fedora development userland).
> >> >
> >> > Have you tested it with the latest fixes that are now in Linus' tree (-rc3)?
> >>
> >> Yes, it was happening with -rc3.
> >
> > Could you please send the bootlog that Yinghai asked for, plus also one that
> > you get with NO_BOOTMEM turned off (for comparison)?
> >
> > Also, when did you first hit this bug? This code has been upstream for almost
> > a month, and it was in linux-next before that - so you should have hit this
> > much sooner. A rough timeframe would suffice. I suppose you were booting
> > upstream kernels during the merge window as well?
> 
> A default y config option causing regressions still at rc3? and you guys 
> keep going? This is the sort of shit Linus would flame me for a day or two 
> for,
> 
> Can we get some f'ing consistency here?

Note, without trying to defend the bootmem conversion itself, which didnt work 
out well, this is not some optional new driver feature that was default-y 
randomly but it was an infrastructure change that was to be made unconditional 
in .35.

The flag was basically a testing/debug flag to allow the old code to be used 
too, in case the new code was buggy. This is what helped James to report this 
today, instead of forcing James through a very difficult ~14-reboot bisection.

Thanks,

	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