linux-kernel - Re: [PATCH] x86: more header fixes

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, 16 Jul 2008 15:46:39 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	"the arch/x86 maintainers" <x86@...nel.org>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] x86: more header fixes

On Wed, Jul 16, 2008 at 3:17 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Ingo Molnar <mingo@...e.hu> wrote:
>
>> thanks. I've picked up these changes and rebased them to -git. (that
>> way they can be maintained as a topic easier) The few files that were
>> left out due to conflicts we can do later on. I pushed the result out
>> into the tip/x86/header-guards topic branch - please double-check that
>> i merged it right.
>
> hm, doesnt work with:
>
> http://redhat.com/~mingo/misc/config-Wed_Jul_16_15_13_24_CEST_2008.bad
>
> include/asm/mpspec.h:39: error: 'MAX_MP_BUSSES' undeclared here (not in
> a function)
> In file included from include/asm/smp.h:15,
>                 from include/linux/smp.h:28,
>                 from include/asm/desc.h:8,
>                 from include/asm/elf.h:89,
>                 from include/linux/elf.h:7,
>                 from arch/x86/boot/compressed/misc.c:29:
> include/asm/io_apic.h:149: error: 'MAX_IRQ_SOURCES' undeclared here (not
> in a function)
>
> etc. Some of those header guards confused some other code i guess.

Yes, you are right. Check out this incredibly hideous hack of
arch/x86/boot/compressed/misc.c:

/*
 * we have to be careful, because no indirections are allowed here, and
 * paravirt_ops is a kind of one. As it will only run in baremetal anyway,
 * we just keep it from happening
 */
#undef CONFIG_PARAVIRT
#ifdef CONFIG_X86_32
#define _ASM_DESC_H_ 1
#endif

#ifdef CONFIG_X86_64
#define _LINUX_STRING_H_ 1
#define __LINUX_BITMAP_H 1
#endif

I'm not sure how we should proceed with this. On one hand, we could
just fix the issues as they come up and be done with it. On the other
hand, this was exactly the thing I wanted to avoid by automatic it. I
guess it can never be fully automated... The question is if there is
any danger of *silent* (read: runtime) breakage, which would be much
worse than compiler errors.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/