Fernando Luis Vazquez Cao <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
