lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 24 Jan 2006 23:10:52 -0800
FromAndrew Morton <>
SubjectRe: [PATCH 1/5] stack overflow safe kdump (2.6.16-rc1-i386) - safe_smp_processor_id
Fernando Luis Vazquez Cao <fernando@intellilink.co.jp> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-25 07:13    [from the cache]
©2003-2008