Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Michal Hocko 
On Mon 23-05-16 09:42:00, Shi, Yang wrote:
> On 5/23/2016 12:31 AM, Michal Hocko wrote:
> > On Fri 20-05-16 08:41:09, Shi, Yang wrote:
> > > On 5/20/2016 6:16 AM, Michal Hocko wrote:
> > > > On Thu 19-05-16 15:13:26, Yang Shi wrote:
> > > > [...]
> > > > > diff --git a/init/main.c b/init/main.c
> > > > > index b3c6e36..2075faf 100644
> > > > > --- a/init/main.c
> > > > > +++ b/init/main.c
> > > > > @@ -606,7 +606,6 @@ asmlinkage __visible void __init 
> > > > > start_kernel(void)
> > > > >   initrd_start = 0;
> > > > >   }
> > > > >  #endif
> > > > > - page_ext_init();
> > > > >   debug_objects_mem_init();
> > > > >   kmemleak_init();
> > > > >   setup_per_cpu_pageset();
> > > > > @@ -1004,6 +1003,8 @@ static noinline void __init 
> > > > > kernel_init_freeable(void)
> > > > >   sched_init_smp();
> > > > > 
> > > > >   page_alloc_init_late();
> > > > > + /* Initialize page ext after all struct pages are initializaed 
> > > > > */
> > > > > + page_ext_init();
> > > > > 
> > > > >   do_basic_setup();
> > > > 
> > > > I might be missing something but don't we have the same problem with
> > > > CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
> > > > CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
> > > 
> > > Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
> > > depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.
> > 
> > Well
> > config MEMORY_HOTPLUG
> > bool "Allow for memory hot-add"
> > depends on SPARSEMEM || X86_64_ACPI_NUMA
> > depends on ARCH_ENABLE_MEMORY_HOTPLUG
> > 
> > I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
> > depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
> > SPARSEMEM only. If the FLATMEM shouldn't exist with
> 
> Actually, FLATMEMT depends on !NUMA.

Ahh, OK, you are right! Thanks for the clarification.
-- 
Michal Hocko
SUSE Labs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Michal Hocko 
On Mon 23-05-16 09:42:00, Shi, Yang wrote:
> On 5/23/2016 12:31 AM, Michal Hocko wrote:
> > On Fri 20-05-16 08:41:09, Shi, Yang wrote:
> > > On 5/20/2016 6:16 AM, Michal Hocko wrote:
> > > > On Thu 19-05-16 15:13:26, Yang Shi wrote:
> > > > [...]
> > > > > diff --git a/init/main.c b/init/main.c
> > > > > index b3c6e36..2075faf 100644
> > > > > --- a/init/main.c
> > > > > +++ b/init/main.c
> > > > > @@ -606,7 +606,6 @@ asmlinkage __visible void __init 
> > > > > start_kernel(void)
> > > > >   initrd_start = 0;
> > > > >   }
> > > > >  #endif
> > > > > - page_ext_init();
> > > > >   debug_objects_mem_init();
> > > > >   kmemleak_init();
> > > > >   setup_per_cpu_pageset();
> > > > > @@ -1004,6 +1003,8 @@ static noinline void __init 
> > > > > kernel_init_freeable(void)
> > > > >   sched_init_smp();
> > > > > 
> > > > >   page_alloc_init_late();
> > > > > + /* Initialize page ext after all struct pages are initializaed 
> > > > > */
> > > > > + page_ext_init();
> > > > > 
> > > > >   do_basic_setup();
> > > > 
> > > > I might be missing something but don't we have the same problem with
> > > > CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
> > > > CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
> > > 
> > > Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
> > > depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.
> > 
> > Well
> > config MEMORY_HOTPLUG
> > bool "Allow for memory hot-add"
> > depends on SPARSEMEM || X86_64_ACPI_NUMA
> > depends on ARCH_ENABLE_MEMORY_HOTPLUG
> > 
> > I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
> > depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
> > SPARSEMEM only. If the FLATMEM shouldn't exist with
> 
> Actually, FLATMEMT depends on !NUMA.

Ahh, OK, you are right! Thanks for the clarification.
-- 
Michal Hocko
SUSE Labs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Shi, Yang 

On 5/23/2016 12:31 AM, Michal Hocko wrote:

On Fri 20-05-16 08:41:09, Shi, Yang wrote:

On 5/20/2016 6:16 AM, Michal Hocko wrote:

On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();

page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();

do_basic_setup();


I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?


Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.


Well
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on ARCH_ENABLE_MEMORY_HOTPLUG

I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
SPARSEMEM only. If the FLATMEM shouldn't exist with


Actually, FLATMEMT depends on !NUMA.


CONFIG_DEFERRED_STRUCT_PAGE_INIT can we make that explicit please?


Sure, it makes the condition clearer and more readable.

Thanks,
Yang

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Shi, Yang 

On 5/23/2016 12:31 AM, Michal Hocko wrote:

On Fri 20-05-16 08:41:09, Shi, Yang wrote:

On 5/20/2016 6:16 AM, Michal Hocko wrote:

On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();

page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();

do_basic_setup();


I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?


Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.


Well
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on ARCH_ENABLE_MEMORY_HOTPLUG

I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
SPARSEMEM only. If the FLATMEM shouldn't exist with


Actually, FLATMEMT depends on !NUMA.


CONFIG_DEFERRED_STRUCT_PAGE_INIT can we make that explicit please?


Sure, it makes the condition clearer and more readable.

Thanks,
Yang

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Michal Hocko 
On Fri 20-05-16 08:41:09, Shi, Yang wrote:
> On 5/20/2016 6:16 AM, Michal Hocko wrote:
> > On Thu 19-05-16 15:13:26, Yang Shi wrote:
> > [...]
> > > diff --git a/init/main.c b/init/main.c
> > > index b3c6e36..2075faf 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
> > >   initrd_start = 0;
> > >   }
> > >  #endif
> > > - page_ext_init();
> > >   debug_objects_mem_init();
> > >   kmemleak_init();
> > >   setup_per_cpu_pageset();
> > > @@ -1004,6 +1003,8 @@ static noinline void __init 
> > > kernel_init_freeable(void)
> > >   sched_init_smp();
> > > 
> > >   page_alloc_init_late();
> > > + /* Initialize page ext after all struct pages are initializaed */
> > > + page_ext_init();
> > > 
> > >   do_basic_setup();
> > 
> > I might be missing something but don't we have the same problem with
> > CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
> > CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
> 
> Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
> depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.

Well
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on ARCH_ENABLE_MEMORY_HOTPLUG

I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
SPARSEMEM only. If the FLATMEM shouldn't exist with
CONFIG_DEFERRED_STRUCT_PAGE_INIT can we make that explicit please?
-- 
Michal Hocko
SUSE Labs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-23 Thread Michal Hocko 
On Fri 20-05-16 08:41:09, Shi, Yang wrote:
> On 5/20/2016 6:16 AM, Michal Hocko wrote:
> > On Thu 19-05-16 15:13:26, Yang Shi wrote:
> > [...]
> > > diff --git a/init/main.c b/init/main.c
> > > index b3c6e36..2075faf 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
> > >   initrd_start = 0;
> > >   }
> > >  #endif
> > > - page_ext_init();
> > >   debug_objects_mem_init();
> > >   kmemleak_init();
> > >   setup_per_cpu_pageset();
> > > @@ -1004,6 +1003,8 @@ static noinline void __init 
> > > kernel_init_freeable(void)
> > >   sched_init_smp();
> > > 
> > >   page_alloc_init_late();
> > > + /* Initialize page ext after all struct pages are initializaed */
> > > + page_ext_init();
> > > 
> > >   do_basic_setup();
> > 
> > I might be missing something but don't we have the same problem with
> > CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
> > CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
> 
> Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which
> depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.

Well
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
depends on SPARSEMEM || X86_64_ACPI_NUMA
depends on ARCH_ENABLE_MEMORY_HOTPLUG

I wasn't really sure about X86_64_ACPI_NUMA dependency branch which
depends on X86_64 && NUMA && ACPI && PCI and that didn't sound like
SPARSEMEM only. If the FLATMEM shouldn't exist with
CONFIG_DEFERRED_STRUCT_PAGE_INIT can we make that explicit please?
-- 
Michal Hocko
SUSE Labs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-20 Thread Shi, Yang 

On 5/20/2016 6:16 AM, Michal Hocko wrote:

On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();

page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();

do_basic_setup();


I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?


Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which 
depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.


Thanks,
Yang

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-20 Thread Shi, Yang 

On 5/20/2016 6:16 AM, Michal Hocko wrote:

On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();

page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();

do_basic_setup();


I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?


Yes, CONFIG_DEFERRED_STRUCT_PAGE_INIT depends on MEMORY_HOTPLUG which 
depends on SPARSEMEM. So, this config is not valid for FLATMEM at all.


Thanks,
Yang

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-20 Thread Michal Hocko 
On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]
> diff --git a/init/main.c b/init/main.c
> index b3c6e36..2075faf 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
>   initrd_start = 0;
>   }
>  #endif
> - page_ext_init();
>   debug_objects_mem_init();
>   kmemleak_init();
>   setup_per_cpu_pageset();
> @@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
>   sched_init_smp();
>  
>   page_alloc_init_late();
> + /* Initialize page ext after all struct pages are initializaed */
> + page_ext_init();
>  
>   do_basic_setup();

I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
-- 
Michal Hocko
SUSE Labs

Re: [v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-20 Thread Michal Hocko 
On Thu 19-05-16 15:13:26, Yang Shi wrote:
[...]
> diff --git a/init/main.c b/init/main.c
> index b3c6e36..2075faf 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
>   initrd_start = 0;
>   }
>  #endif
> - page_ext_init();
>   debug_objects_mem_init();
>   kmemleak_init();
>   setup_per_cpu_pageset();
> @@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
>   sched_init_smp();
>  
>   page_alloc_init_late();
> + /* Initialize page ext after all struct pages are initializaed */
> + page_ext_init();
>  
>   do_basic_setup();

I might be missing something but don't we have the same problem with
CONFIG_FLATMEM? page_ext_init_flatmem is called way earlier. Or
CONFIG_DEFERRED_STRUCT_PAGE_INIT is never enabled for CONFIG_FLATMEM?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Shi, Yang 

On 5/19/2016 4:21 PM, Andrew Morton wrote:

On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang"  wrote:


On 5/19/2016 3:30 PM, Andrew Morton wrote:

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:


When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.



When fixing a bug, please fully describe the end-user impact
of that bug


The kernel ran into the below oops which is same with the oops reported
in
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.


So this patch makes
mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch
obsolete?


Actually, no. Checking the return value for lookup_page_ext() is still 
needed. But, the commit log need to be amended since that bootup oops 
won't happen anymore with this patch applied.


Thanks,
Yang

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Shi, Yang 

On 5/19/2016 4:21 PM, Andrew Morton wrote:

On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang"  wrote:


On 5/19/2016 3:30 PM, Andrew Morton wrote:

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:


When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.



When fixing a bug, please fully describe the end-user impact
of that bug


The kernel ran into the below oops which is same with the oops reported
in
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.


So this patch makes
mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch
obsolete?


Actually, no. Checking the return value for lookup_page_ext() is still 
needed. But, the commit log need to be amended since that bootup oops 
won't happen anymore with this patch applied.


Thanks,
Yang

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Andrew Morton 
On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang"  wrote:

> On 5/19/2016 3:30 PM, Andrew Morton wrote:
> > On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:
> >
> >> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
> >> are initialized, then the rest are initialized in parallel by starting 
> >> one-off
> >> "pgdatinitX" kernel thread for each node X.
> >>
> >> If page_ext_init is called before it, some pages will not have valid 
> >> extension,
> >> so move page_ext_init() after it.
> >>
> >
> > When fixing a bug, please fully describe the end-user impact
> > of that bug
> 
> The kernel ran into the below oops which is same with the oops reported 
> in 
> http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.

So this patch makes
mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch
obsolete?

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Andrew Morton 
On Thu, 19 May 2016 15:35:15 -0700 "Shi, Yang"  wrote:

> On 5/19/2016 3:30 PM, Andrew Morton wrote:
> > On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:
> >
> >> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
> >> are initialized, then the rest are initialized in parallel by starting 
> >> one-off
> >> "pgdatinitX" kernel thread for each node X.
> >>
> >> If page_ext_init is called before it, some pages will not have valid 
> >> extension,
> >> so move page_ext_init() after it.
> >>
> >
> > When fixing a bug, please fully describe the end-user impact
> > of that bug
> 
> The kernel ran into the below oops which is same with the oops reported 
> in 
> http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.

So this patch makes
mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch
obsolete?

[v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Yang Shi 
When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
this may lead the below kernel oops when booting up kernel:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] free_pcppages_bulk+0x2d2/0x8d0
PGD 0
Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS 
S5500.86B.01.10.0025.030220091519 03/02/2009
task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
RIP: 0010:[]  [] 
free_pcppages_bulk+0x2d2/0x8d0
RSP: :88017c087c48  EFLAGS: 00010046
RAX:  RBX:  RCX: 0001
RDX: 0980 RSI: 0080 RDI: 00660401
RBP: 88017c087cd0 R08: 0401 R09: 0009
R10: 88017c080040 R11: 000a R12: 0400
R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
FS:  () GS:88066cd4() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 02406000 CR4: 06e0
Stack:
 88066cd5bbd8 88066cfe6640  
 001f001f 88066cd5bbe8 ea001981 8118f53e
 0009 0401 000a 0001
Call Trace:
 [] free_hot_cold_page+0x192/0x1d0
 [] __free_pages+0x5c/0x90
 [] __free_pages_boot_core+0x11a/0x14e
 [] deferred_free_range+0x50/0x62
 [] deferred_init_memmap+0x220/0x3c3
 [] ? setup_per_cpu_pageset+0x35/0x35
 [] kthread+0xf8/0x110
 [] ret_from_fork+0x22/0x40
 [] ? kthread_create_on_node+0x200/0x200
Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8 4c 89 
45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 00 44 8b 5d c8 
4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff
RIP  [] free_pcppages_bulk+0x2d2/0x8d0
 RSP 
CR2: 

Move page_ext_init() after page_alloc_init_late() to make sure page extension
is setup for all pages.

CC: Joonsoo Kim 
Signed-off-by: Yang Shi 
---
Changelog v1 --> v2:
 Added bug description in the commit log per Andrew's comment

 init/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();
 
page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();
 
do_basic_setup();
 
-- 
2.0.2

[v2 PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Yang Shi 
When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
this may lead the below kernel oops when booting up kernel:

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] free_pcppages_bulk+0x2d2/0x8d0
PGD 0
Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS 
S5500.86B.01.10.0025.030220091519 03/02/2009
task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
RIP: 0010:[]  [] 
free_pcppages_bulk+0x2d2/0x8d0
RSP: :88017c087c48  EFLAGS: 00010046
RAX:  RBX:  RCX: 0001
RDX: 0980 RSI: 0080 RDI: 00660401
RBP: 88017c087cd0 R08: 0401 R09: 0009
R10: 88017c080040 R11: 000a R12: 0400
R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
FS:  () GS:88066cd4() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 02406000 CR4: 06e0
Stack:
 88066cd5bbd8 88066cfe6640  
 001f001f 88066cd5bbe8 ea001981 8118f53e
 0009 0401 000a 0001
Call Trace:
 [] free_hot_cold_page+0x192/0x1d0
 [] __free_pages+0x5c/0x90
 [] __free_pages_boot_core+0x11a/0x14e
 [] deferred_free_range+0x50/0x62
 [] deferred_init_memmap+0x220/0x3c3
 [] ? setup_per_cpu_pageset+0x35/0x35
 [] kthread+0xf8/0x110
 [] ret_from_fork+0x22/0x40
 [] ? kthread_create_on_node+0x200/0x200
Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8 4c 89 
45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 00 44 8b 5d c8 
4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff
RIP  [] free_pcppages_bulk+0x2d2/0x8d0
 RSP 
CR2: 

Move page_ext_init() after page_alloc_init_late() to make sure page extension
is setup for all pages.

CC: Joonsoo Kim 
Signed-off-by: Yang Shi 
---
Changelog v1 --> v2:
 Added bug description in the commit log per Andrew's comment

 init/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();
 
page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();
 
do_basic_setup();
 
-- 
2.0.2

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Shi, Yang 

On 5/19/2016 3:30 PM, Andrew Morton wrote:

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:


When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.



When fixing a bug, please fully describe the end-user impact
of that bug


The kernel ran into the below oops which is same with the oops reported 
in 
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.


BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] free_pcppages_bulk+0x2d2/0x8d0
PGD 0
Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS 
S5500.86B.01.10.0025.030220091519 03/02/2009

task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
RIP: 0010:[]  [] 
free_pcppages_bulk+0x2d2/0x8d0

RSP: :88017c087c48  EFLAGS: 00010046
RAX:  RBX:  RCX: 0001
RDX: 0980 RSI: 0080 RDI: 00660401
RBP: 88017c087cd0 R08: 0401 R09: 0009
R10: 88017c080040 R11: 000a R12: 0400
R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
FS:  () GS:88066cd4() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 02406000 CR4: 06e0
Stack:
 88066cd5bbd8 88066cfe6640  
 001f001f 88066cd5bbe8 ea001981 8118f53e
 0009 0401 000a 0001
Call Trace:
 [] free_hot_cold_page+0x192/0x1d0
 [] __free_pages+0x5c/0x90
 [] __free_pages_boot_core+0x11a/0x14e
 [] deferred_free_range+0x50/0x62
 [] deferred_init_memmap+0x220/0x3c3
 [] ? setup_per_cpu_pageset+0x35/0x35
 [] kthread+0xf8/0x110
 [] ret_from_fork+0x22/0x40
 [] ? kthread_create_on_node+0x200/0x200
Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8 
4c 89 45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 
00 44 8b 5d c8 4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff

RIP  [] free_pcppages_bulk+0x2d2/0x8d0
 RSP 
CR2: 


I will add the oops info into the commit log in V2.

Thanks,
Yang

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Shi, Yang 

On 5/19/2016 3:30 PM, Andrew Morton wrote:

On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:


When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.



When fixing a bug, please fully describe the end-user impact
of that bug


The kernel ran into the below oops which is same with the oops reported 
in 
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_is_guard-return-false-when-page_ext-arrays-are-not-allocated-yet.patch.


BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] free_pcppages_bulk+0x2d2/0x8d0
PGD 0
Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU: 11 PID: 106 Comm: pgdatinit1 Not tainted 4.6.0-rc5-next-20160427 #26
Hardware name: Intel Corporation S5520HC/S5520HC, BIOS 
S5500.86B.01.10.0025.030220091519 03/02/2009

task: 88017c080040 ti: 88017c084000 task.ti: 88017c084000
RIP: 0010:[]  [] 
free_pcppages_bulk+0x2d2/0x8d0

RSP: :88017c087c48  EFLAGS: 00010046
RAX:  RBX:  RCX: 0001
RDX: 0980 RSI: 0080 RDI: 00660401
RBP: 88017c087cd0 R08: 0401 R09: 0009
R10: 88017c080040 R11: 000a R12: 0400
R13: ea001981 R14: ea0019810040 R15: 88066cfe6080
FS:  () GS:88066cd4() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 02406000 CR4: 06e0
Stack:
 88066cd5bbd8 88066cfe6640  
 001f001f 88066cd5bbe8 ea001981 8118f53e
 0009 0401 000a 0001
Call Trace:
 [] free_hot_cold_page+0x192/0x1d0
 [] __free_pages+0x5c/0x90
 [] __free_pages_boot_core+0x11a/0x14e
 [] deferred_free_range+0x50/0x62
 [] deferred_init_memmap+0x220/0x3c3
 [] ? setup_per_cpu_pageset+0x35/0x35
 [] kthread+0xf8/0x110
 [] ret_from_fork+0x22/0x40
 [] ? kthread_create_on_node+0x200/0x200
Code: 49 89 d4 48 c1 e0 06 49 01 c5 e9 de fe ff ff 4c 89 f7 44 89 4d b8 
4c 89 45 c0 44 89 5d c8 48 89 4d d0 e8 62 c7 07 00 48 8b 4d d0 <48> 8b 
00 44 8b 5d c8 4c 8b 45 c0 44 8b 4d b8 a8 02 0f 84 05 ff

RIP  [] free_pcppages_bulk+0x2d2/0x8d0
 RSP 
CR2: 


I will add the oops info into the commit log in V2.

Thanks,
Yang

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Andrew Morton 
On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:

> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
> are initialized, then the rest are initialized in parallel by starting one-off
> "pgdatinitX" kernel thread for each node X.
> 
> If page_ext_init is called before it, some pages will not have valid 
> extension,
> so move page_ext_init() after it.
> 

When fixing a bug, please fully describe the end-user impact
of that bug

Re: [PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Andrew Morton 
On Thu, 19 May 2016 14:29:05 -0700 Yang Shi  wrote:

> When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
> are initialized, then the rest are initialized in parallel by starting one-off
> "pgdatinitX" kernel thread for each node X.
> 
> If page_ext_init is called before it, some pages will not have valid 
> extension,
> so move page_ext_init() after it.
> 

When fixing a bug, please fully describe the end-user impact
of that bug

[PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Yang Shi 
When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.

CC: Joonsoo Kim 
Signed-off-by: Yang Shi 
---
 init/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();
 
page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();
 
do_basic_setup();
 
-- 
2.0.2

[PATCH] mm: move page_ext_init after all struct pages are initialized

2016-05-19 Thread Yang Shi 
When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot
are initialized, then the rest are initialized in parallel by starting one-off
"pgdatinitX" kernel thread for each node X.

If page_ext_init is called before it, some pages will not have valid extension,
so move page_ext_init() after it.

CC: Joonsoo Kim 
Signed-off-by: Yang Shi 
---
 init/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init/main.c b/init/main.c
index b3c6e36..2075faf 100644
--- a/init/main.c
+++ b/init/main.c
@@ -606,7 +606,6 @@ asmlinkage __visible void __init start_kernel(void)
initrd_start = 0;
}
 #endif
-   page_ext_init();
debug_objects_mem_init();
kmemleak_init();
setup_per_cpu_pageset();
@@ -1004,6 +1003,8 @@ static noinline void __init kernel_init_freeable(void)
sched_init_smp();
 
page_alloc_init_late();
+   /* Initialize page ext after all struct pages are initializaed */
+   page_ext_init();
 
do_basic_setup();
 
-- 
2.0.2