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

[James Bottomley <James.Bottomley@SteelEye.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/