On Thu, Jan 23, 2014 at 01:49:28PM +0800, Tang Chen wrote:
> This doesn't always happen. According to Dave, this happened once
> in about five boots. The backtrace is like the following:
>
> dump_stack
> panic
> ? numa_clear_kernel_node_hotplug
> __stack_chk_fail
> numa_clear_kernel_node_hotplug
> ? memblock_search_pfn_nid
> ? __early_pfn_to_nid
> numa_init
> x86_numa_init
> initmem_init
> setup_arch
> start_kernel
>
> This patch fix this problem by defining numa_kernel_nodes as a
> static global variable in __initdata area.
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 81b2750..ebefeb7 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> }
> }
>
> +static nodemask_t numa_kernel_nodes __initdata;
> static void __init numa_clear_kernel_node_hotplug(void)
> {
> int i, nid;
> - nodemask_t numa_kernel_nodes;
> unsigned long start, end;
> struct memblock_type *type = &memblock.reserved;
I'm surprised that this worked for anyone.
By my math, nodemask_t is 1024 longs, which should fill the whole stack.
Any idea why it only broke sometimes ?
There are other on-stack nodemask_t's in the tree too, why are they safe ?
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
