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

[Andrew Morton]

Fernando Luis Vazquez Cao <fernando@xxxxxxxxxxxxxxxxx> wrote:
>
> On the event of a stack overflow critical data that usually resides at
> the bottom of the stack is likely to be stomped and, consequently, its
> use should be avoided.
> 
> In particular, in the i386 and IA64 architectures the macro
> smp_processor_id ultimately makes use of the "cpu" member of struct
> thread_info which resides at the bottom of the stack. x86_64, on the
> other hand, is not affected by this problem because it benefits from
> the use of the PDA infrastructure.
> 
> To circumvent this problem I suggest implementing
> "safe_smp_processor_id()" (it already exists in x86_64) for i386 and
> IA64 and use it as a replacement for smp_processor_id in the reboot path
> to the dump capture kernel. This is a possible implementation for i386.
> 
> ...
>
> +int safe_smp_processor_id(void) {

Please fix coding style.

>  #endif
>  
> +extern int safe_smp_processor_id(void);
>  extern int __cpu_disable(void);
>  extern void __cpu_die(unsigned int cpu);
>  #endif /* !__ASSEMBLY__ */
>  
>  #else /* CONFIG_SMP */
>  
> +#define safe_smp_processor_id() 0
>  #define cpu_physical_id(cpu)		boot_cpu_physical_apicid

It assumes that all x86 SMP machines have APICs.  That's untrue of Voyager.
I think we can probably live with this assumption - others would know
better than I.
-
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/