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
| ||
|
Message-ID: <alpine.DEB.2.00.1212261343210.20193@chino.kir.corp.google.com>
Date: Wed, 26 Dec 2012 14:00:23 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: David Woodhouse <dwmw2@...radead.org>
cc: Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
tglx@...utronix.de, "H. Peter Anvin" <hpa@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding
CONFIG_64BIT
On Wed, 26 Dec 2012, David Woodhouse wrote:
> > I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest
> > related to these subsystems and I'm sure it's just because my randconfig
> > builds were exposed to this combination solely because of this patch.
>
> Hm, that's an unexpected benefit of this patch. I didn't think it would
> noticeably improve 'make randconfig' coverage of configs without
> CONFIG_64BIT, because I thought enough people were doing such tests
> already. But evidently I was wrong.
>
I do quite a bit of automated config and boot tests to try out
combinations that others may not have tested when developing their code;
staging branches such as in tip are interesting to try because they
haven't yet reached Linus and it's helpful to catch breakages before it
reaches mainline.
> We introduced 'make randconfig' as a tool to generate meaningless
> configs just to test various permutations — to ensure that we got our
> dependencies right both in Kconfig and the code itself. It was
> artificially limiting its test coverage and thus we were failing to
> discover real bugs. Now I've fixed that problem, and 'make randconfig'
> is actually random and is thus doing its job even better than before.
> Yay!
>
Umm, you're saying that is legitimate for "make randconfig" done on a
32-bit machine to generate 64-bit configurations? The resulting kernel
cannot be booted. In the past, "make randconfig" would always generate a
kernel that _should_ boot on that machine unless there was an underlying
bug that should be fixed.
> > > Please could you provide the .config file?
>
> > Attached.
>
> Didn't seem to be.
>
Now it is, sorry.
> I just don't buy this "OMG you made randconfig actually random" crap.
> It's a stupid thing to complain about. Making some effort to pick
> i386_defconfig or x86_64_defconfig according to the build host, we can
> tolerate. But randconfig is *supposed* to be random. Get over it.
>
I'm stupid for saying that you've changed the behavior of "make
randconfig" with no ARCH= workaround so that it may result in an
unbootable kernel on i386? From the changelog of this commit, it looks
like you're the idiot who can't remember he's building a 32-bit kernel on
a 64-bit machine and is throwing a hissy fit because YOU forgot to put
ARCH=i386. But now you're pushing that obligation, which is a change from
the previous behavior for years, on everyone else to workaround?
View attachment "config.tip.tip.auto-latest.for-woodhouse" of type "TEXT/PLAIN" (92766 bytes)
Powered by blists - more mailing lists