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]

Message-ID: <1356511396.7010.13.camel@shinybook.infradead.org>
Date:	Wed, 26 Dec 2012 08:43:16 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Rientjes <rientjes@...gle.com>
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 Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
> This creates quite a few build failures on auto-latest:
>
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> arch/x86/built-in.o: In function `hpet_msi_capability_lookup':
> hpet.c:(.text+0x347ff): undefined reference to `create_irq_nr'
> arch/x86/built-in.o:(.data+0xd1c): undefined reference to `native_setup_msi_irqs'
> arch/x86/built-in.o:(.data+0xd20): undefined reference to `native_teardown_msi_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89eec0): undefined reference to `create_irq'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef0b): undefined reference to `arch_setup_dmar_msi'
> drivers/built-in.o: In function `dmar_set_interrupt':
> (.text+0x89ef44): undefined reference to `destroy_irq'
> drivers/built-in.o: In function `free_dmar_iommu':
> (.text+0x8a6ae8): undefined reference to `destroy_irq'
> 
> These functions require CONFIG_X86_IO_APIC, which is only possible with 
> X86_64 or X86_32_NON_STANDARD.  CONFIG_HPET_TIMER, however, can be enabled 
> with X86_32, and CONFIG_DMAR_TABLE can be enabled with any X86 via 
> CONFIG_INTEL_IOMMU.

I don't think it can have created them, surely? They must have existed
already when building with ARCH=x86. And probably with ARCH=i386 too?
I'll take a further look in more detail, but at first glance it doesn't
seem correct to describe them as bugs caused by this patch; merely bugs
that this patch helped us to *find*.

Please could you provide the .config file?

> That said, I didn't try to fix this up because I believe the commit itself 
> is wrong. 

That seems like completely the wrong approach.

>  When I do "make randconfig" and uname -m is x86_64, I expect 
> CONFIG_64BIT to always be set.  This commit makes this random for all x86 
> so that "make randconfig" may result in a 32-bit build.  That should be 
> the behavior for "make ARCH=i386 randconfig" but not "make randconfig" on 
> a 64-bit machine.

We've had this bizarre "I don't really want randconfig to be random"
conversation before. If don't want randconfig to be random, you can use
$KCONFIG_ALLCONFIG to override anything you like. Or, for the specific
case of CONFIG_64BIT on x86, you can use ARCH=i386 or ARCH=x86_64 to
override just that one option.

I'll look at the dependency problems that already existed, and try to
sort them out despite the fact that they seem unrelated to the patch I
posted. Thanks for reporting them.

-- 
dwmw2


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)