Re: [RFC][PATCH] kmemcheck: divide and conquer

["Vegard Nossum" <vegard.nossum@gmail.com>]

On Mon, Jun 16, 2008 at 7:15 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> -tip testing found a build failure with kmemcheck:
>
> include/asm/string_32.h:320:1: warning: "memset" redefined
> include/asm/string_32.h:245:1: warning: this is the location of the previous definition
>
> arch/x86/mm/kmemcheck/smp.c: In function 'kmemcheck_pause_allbutself':
> arch/x86/mm/kmemcheck/smp.c:59: error: 'NMI_VECTOR' undeclared (first use in this function)
> arch/x86/mm/kmemcheck/smp.c:59: error: (Each undeclared identifier is reported only once
> arch/x86/mm/kmemcheck/smp.c:59: error: for each function it appears in.)
>
> with this config:
>
>  http://redhat.com/~mingo/misc/config-Mon_Jun_16_04_15_22_CEST_2008.bad
>
> the patch below fixes the build failure, but note that there are lots of
> those memset redefined warnings with that config as well.

Thanks. I get the error with that config as well.

> @@ -5,6 +5,7 @@
>  #include <mach_ipi.h>
>
>  #include "smp.h"
> +#include <asm/irq_vectors.h>
>
>  static spinlock_t nmi_spinlock;

However, the real error is that I'm including <mach_ipi.h> which for
the default config resolves to
include/asm-x86/mach-default/mach_ipi.h. All the mach-*/mach_ipi.h
files exist, but only one of them define NMI_VECTOR.

But your config has CONFIG_X86_BIGSMP=y.

For some reason, there is no <asm/irq_vectors.h> in my repository, so
I assume the change came from another branch. In fact, I should have
included <asm/hw_irq.h>, but that doesn't contain the right
definitions in the tip/auto-test branch.

Yep, seems to be

commit 9b7dc567d03d74a1fbae84e88949b6a60d922d82
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri May 2 20:10:09 2008 +0200

    x86: unify interrupt vector defines

I also can't seem to get the redefined warnings, so I assume that's
also just an indirect conflict with other -tip changes.

Right now, I am reluctant to apply your fix because it means that
kmemcheck tree won't build as it is. In general, what's the way to
resolve these things? Do you have another branch, *-fixes, where these
fixlets can go until either of the conflicting changesets are merged
upstream? If so, it seems that that would be the right place for this
patch. Do you agree or do you have another solution? :-)

Thanks!


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