linux-kernel - Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG

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, 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)