Re: [PATCH 1/3] stack overflow safe kdump (2.6.18-rc1-i386) -safe_smp_processor_id

From: James Bottomley
Date: Mon Jul 10 2006 - 10:15:39 EST


On Mon, 2006-07-10 at 16:50 +0900, Fernando Luis VÃzquez Cao wrote:
> diff -urNp linux-2.6.18-rc1/include/asm-i386/smp.h
> linux-2.6.18-rc1-sof/include/asm-i386/smp.h
> --- linux-2.6.18-rc1/include/asm-i386/smp.h 2006-07-10
> 11:00:05.000000000 +0900
> +++ linux-2.6.18-rc1-sof/include/asm-i386/smp.h 2006-07-10
> 15:34:26.000000000 +0900
> @@ -89,12 +89,20 @@ static __inline int logical_smp_processo
>
> #endif
>
> +#ifdef CONFIG_X86_VOYAGER
> +extern int hard_smp_processor_id(void);
> +#define safe_smp_processor_id() hard_smp_processor_id()
> +#else
> +extern int safe_smp_processor_id(void);
> +#endif
> +

Argh, no, don't do this. The Subarchitecture specific code should never
appear in the standard include directory (that was about the whole
point). The extern for hard_smp_processor_id should just be global,
since it's common to all architectures, and the voyager specific define
should be in a voyager specific header file.

As an aside, it shows the problems x86 got itself into with it's
inconsistent direction of physical vs logical CPUs. The idea was that
smp_processor_id() and hard_smp_processor_id() were supposed to return
the same thing, only hard_... went to the actual SMP registers to get
it.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/