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)

Powered by blists - more mailing lists