Hi Dave,
I think here is the overflow problem. Not the stackoverflow,
but the array index overflow.
Please have a look at the following path:
numa_init()
|---> numa_register_memblks()
| |---> memblock_set_node(memory) set correct nid in
memblock.memory
| |--->
On Tue, Jan 28, 2014 at 01:17:21PM +0800, Tang Chen wrote:
> Seeing from your earlier mail, it crashed at:
>
> while (zonelist_zone_idx(z) > highest_zoneidx)
>de: 3b 77 08cmp0x8(%rdi),%esi
>
>
> I stuck this at the top of the function..
>
On 01/28/2014 12:47 PM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
> On 01/28/2014 11:55 AM, Dave Jones wrote:
> > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
> >
> >> > I did a bisect with the patch above applied each step of
On 01/28/2014 12:47 PM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
> On 01/28/2014 11:55 AM, Dave Jones wrote:
> > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
> >
> >> > I did a bisect with the patch above applied each step of
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
> On 01/28/2014 11:55 AM, Dave Jones wrote:
> > On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
> >
> > > > I did a bisect with the patch above applied each step of the way.
> > > > This time I got a plausible
On 01/28/2014 11:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
> > I did a bisect with the patch above applied each step of the way.
> > This time I got a plausible looking result
>
> I cannot reproduce this. Would you please share how to
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
> > I did a bisect with the patch above applied each step of the way.
> > This time I got a plausible looking result
>
> I cannot reproduce this. Would you please share how to reproduce it ?
> Or does it just happen during the
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>>arch/x86/mm/numa.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>>arch/x86/mm/numa.c | 2 +-
> >>>1 file changed, 1 insertion(+), 1
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
> On 01/28/2014 08:32 AM, David Rientjes wrote:
> > On Wed, 22 Jan 2014, David Rientjes wrote:
> >
> >>> arch/x86/mm/numa.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/x86/mm/numa.c
On 01/28/2014 08:32 AM, David Rientjes wrote:
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 81b2750..ebefeb7 100644
--- a/arch/x86/mm/numa.c
+++
On Wed, 22 Jan 2014, David Rientjes wrote:
> > arch/x86/mm/numa.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > 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
On Mon, Jan 27, 2014 at 03:29:03PM +0800, Tang Chen wrote:
> > Some build tests show..
> >
> > MAXSMP ( NODESHIFT=10 ) : Bug
> > NRCPUS=4& NODESHIFT=10 : Bug
> > NRCPUS=4& NODESHIFT=1 : no bug
> >
> >
> > The middle config test was accidental, I hadn't realised disabling MAXSMP
> >
On Mon, Jan 27, 2014 at 03:29:03PM +0800, Tang Chen wrote:
Some build tests show..
MAXSMP ( NODESHIFT=10 ) : Bug
NRCPUS=4 NODESHIFT=10 : Bug
NRCPUS=4 NODESHIFT=1 : no bug
The middle config test was accidental, I hadn't realised disabling MAXSMP
wouldn't reset
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
On 01/28/2014 08:32 AM, David Rientjes wrote:
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 81b2750..ebefeb7 100644
--- a/arch/x86/mm/numa.c
+++
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
On 01/28/2014 08:32 AM, David Rientjes wrote:
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
On 01/28/2014 08:32 AM, David Rientjes wrote:
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 01/28/2014 10:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 09:01:25AM +0800, Tang Chen wrote:
On 01/28/2014 08:32 AM, David Rientjes wrote:
On Wed, 22 Jan 2014, David Rientjes wrote:
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
I cannot reproduce this. Would you please share how to reproduce it ?
Or does it just happen during the booting
On 01/28/2014 11:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
I cannot reproduce this. Would you please share how to
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
On 01/28/2014 11:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
I did a bisect with the patch above applied each step of the way.
This time I got a plausible looking result
On 01/28/2014 12:47 PM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
On 01/28/2014 11:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
I did a bisect with the patch above applied each step of the
On 01/28/2014 12:47 PM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 12:47:11PM +0800, Tang Chen wrote:
On 01/28/2014 11:55 AM, Dave Jones wrote:
On Tue, Jan 28, 2014 at 11:24:37AM +0800, Tang Chen wrote:
I did a bisect with the patch above applied each step of the
On Tue, Jan 28, 2014 at 01:17:21PM +0800, Tang Chen wrote:
Seeing from your earlier mail, it crashed at:
while (zonelist_zone_idx(z) highest_zoneidx)
de: 3b 77 08cmp0x8(%rdi),%esi
I stuck this at the top of the function..
Hi Dave,
I think here is the overflow problem. Not the stackoverflow,
but the array index overflow.
Please have a look at the following path:
numa_init()
|--- numa_register_memblks()
| |--- memblock_set_node(memory) set correct nid in
memblock.memory
| |---
On 01/24/2014 06:31 AM, Dave Jones wrote:
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
> 128 bytes is a pretty small amount of stack though, so I'm just as confused
> as to what the actual bug here is.
>
> After trying the proposed fix, I got another oops in the
On 01/24/2014 06:31 AM, Dave Jones wrote:
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
128 bytes is a pretty small amount of stack though, so I'm just as confused
as to what the actual bug here is.
After trying the proposed fix, I got another oops in the early
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
> 128 bytes is a pretty small amount of stack though, so I'm just as confused
> as to what the actual bug here is.
>
> After trying the proposed fix, I got another oops in the early init code..
>
>
> nr_free_zone_pages
>
On Wed, Jan 22, 2014 at 10:15:51PM -0800, David Rientjes wrote:
> On Thu, 23 Jan 2014, Dave Jones wrote:
>
> > It's 10, because I had MAXSMP set.
> >
> > So, MAX_NUMNODES = 1 << 10
> >
> > And the bitmask is made of longs. 1024 of them.
> >
> > How does this work ?
> >
>
> It's
On Wed, Jan 22, 2014 at 10:15:51PM -0800, David Rientjes wrote:
On Thu, 23 Jan 2014, Dave Jones wrote:
It's 10, because I had MAXSMP set.
So, MAX_NUMNODES = 1 10
And the bitmask is made of longs. 1024 of them.
How does this work ?
It's 1024 bits.
ok, I got
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
128 bytes is a pretty small amount of stack though, so I'm just as confused
as to what the actual bug here is.
After trying the proposed fix, I got another oops in the early init code..
trace
nr_free_zone_pages
On 01/23/2014 02:13 PM, Dave Jones wrote:
On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
> On Thu, 23 Jan 2014, Tang Chen wrote:
>
..
>
> I guess it depends on what Dave's CONFIG_NODES_SHIFT is?
It's 10, because I had MAXSMP set.
So, MAX_NUMNODES = 1<< 10
And
On Thu, 23 Jan 2014, Dave Jones wrote:
> It's 10, because I had MAXSMP set.
>
> So, MAX_NUMNODES = 1 << 10
>
> And the bitmask is made of longs. 1024 of them.
>
> How does this work ?
>
It's 1024 bits.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
> On Thu, 23 Jan 2014, Tang Chen wrote:
>
> > Dave found that the kernel will hang during boot. This is because
> > the nodemask_t type stack variable numa_kernel_nodes is large enough
> > to overflow the stack.
> >
> > This
On Thu, 23 Jan 2014, Tang Chen wrote:
> Dave found that the kernel will hang during boot. This is because
> the nodemask_t type stack variable numa_kernel_nodes is large enough
> to overflow the stack.
>
> This doesn't always happen. According to Dave, this happened once
> in about five boots.
On Thu, 23 Jan 2014 13:49:28 +0800 Tang Chen wrote:
> Dave found that the kernel will hang during boot. This is because
> the nodemask_t type stack variable numa_kernel_nodes is large enough
> to overflow the stack.
>
> This doesn't always happen. According to Dave, this happened once
> in
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
>
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't always happen. According to Dave, this happened once
in about five boots. The backtrace is like the following:
dump_stack
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't always happen. According to Dave, this happened once
in about five boots. The backtrace is like the following:
dump_stack
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
On Thu, 23 Jan 2014 13:49:28 +0800 Tang Chen tangc...@cn.fujitsu.com wrote:
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't always happen. According to Dave, this
On Thu, 23 Jan 2014, Tang Chen wrote:
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't always happen. According to Dave, this happened once
in about five boots. The
On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
On Thu, 23 Jan 2014, Tang Chen wrote:
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't
On Thu, 23 Jan 2014, Dave Jones wrote:
It's 10, because I had MAXSMP set.
So, MAX_NUMNODES = 1 10
And the bitmask is made of longs. 1024 of them.
How does this work ?
It's 1024 bits.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 01/23/2014 02:13 PM, Dave Jones wrote:
On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote:
On Thu, 23 Jan 2014, Tang Chen wrote:
..
I guess it depends on what Dave's CONFIG_NODES_SHIFT is?
It's 10, because I had MAXSMP set.
So, MAX_NUMNODES = 1 10
And the
46 matches
Mail list logo
