Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-02 Thread Shi, Yang 

On 6/1/2016 10:00 PM, Minchan Kim wrote:

On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote:

On 5/29/2016 11:11 PM, Minchan Kim wrote:

On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:





If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this
should be only possible to happen on 32 bit since just 32 bit
version page_is_idle() calls lookup_page_ext(), it doesn't do it on
64 bit.

And, such race condition should exist regardless of whether DEBUG_VM
is enabled or not, right?

rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index 8f5d4ad..bf0cd6a 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -77,8 +77,12 @@ static inline bool
test_and_clear_page_young(struct page *page)
static inline bool page_is_idle(struct page *page)
{
   struct page_ext *page_ext;
+
+   rcu_read_lock();
   page_ext = lookup_page_ext(page);
+   rcu_read_unlock();
+
if (unlikely(!page_ext))
   return false;

diff --git a/mm/page_ext.c b/mm/page_ext.c
index 56b160f..94927c9 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
{
   unsigned long pfn = page_to_pfn(page);
   struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
   /*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
   if (!section->page_ext)
   return NULL;
-#endif
+
   return section->page_ext + pfn;
}

@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
   return;
   base = ms->page_ext + pfn;
   free_page_ext(base);
-   ms->page_ext = NULL;
+   rcu_assign_pointer(ms->page_ext, NULL);
+   synchronize_rcu();


How does it fix the problem?
I cannot understand your point.


Assigning NULL pointer to page_Ext will be blocked until
rcu_read_lock critical section is done, so the lookup and writing
operations will be serialized. And, rcu_read_lock disables preempt
too.


I meant your rcu_read_lock in page_idle should cover test_bit op.


Yes, definitely. Thanks for catching it.


One more thing, you should use rcu_dereference.


I will check which one is the best since I saw some use rcu_assign_pointer.



As well, please cover memory onlining case I mentioned in another
thread as well as memory offlining.


I will look into it too.

Thanks,
Yang



Anyway, to me, every caller of page_ext should prepare lookup_page_ext
can return NULL anytime and they should use rcu_read_[un]lock, which
is not good. :(

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-02 Thread Shi, Yang 

On 6/1/2016 10:00 PM, Minchan Kim wrote:

On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote:

On 5/29/2016 11:11 PM, Minchan Kim wrote:

On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:





If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this
should be only possible to happen on 32 bit since just 32 bit
version page_is_idle() calls lookup_page_ext(), it doesn't do it on
64 bit.

And, such race condition should exist regardless of whether DEBUG_VM
is enabled or not, right?

rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index 8f5d4ad..bf0cd6a 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -77,8 +77,12 @@ static inline bool
test_and_clear_page_young(struct page *page)
static inline bool page_is_idle(struct page *page)
{
   struct page_ext *page_ext;
+
+   rcu_read_lock();
   page_ext = lookup_page_ext(page);
+   rcu_read_unlock();
+
if (unlikely(!page_ext))
   return false;

diff --git a/mm/page_ext.c b/mm/page_ext.c
index 56b160f..94927c9 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
{
   unsigned long pfn = page_to_pfn(page);
   struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
   /*
* The sanity checks the page allocator does upon freeing a
* page can reach here before the page_ext arrays are
@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
*/
   if (!section->page_ext)
   return NULL;
-#endif
+
   return section->page_ext + pfn;
}

@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
   return;
   base = ms->page_ext + pfn;
   free_page_ext(base);
-   ms->page_ext = NULL;
+   rcu_assign_pointer(ms->page_ext, NULL);
+   synchronize_rcu();


How does it fix the problem?
I cannot understand your point.


Assigning NULL pointer to page_Ext will be blocked until
rcu_read_lock critical section is done, so the lookup and writing
operations will be serialized. And, rcu_read_lock disables preempt
too.


I meant your rcu_read_lock in page_idle should cover test_bit op.


Yes, definitely. Thanks for catching it.


One more thing, you should use rcu_dereference.


I will check which one is the best since I saw some use rcu_assign_pointer.



As well, please cover memory onlining case I mentioned in another
thread as well as memory offlining.


I will look into it too.

Thanks,
Yang



Anyway, to me, every caller of page_ext should prepare lookup_page_ext
can return NULL anytime and they should use rcu_read_[un]lock, which
is not good. :(

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Minchan Kim 
On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote:
> On 5/29/2016 11:11 PM, Minchan Kim wrote:
> >On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:
> >
> >
> >
> >>>
> >>>If we goes this way, how to guarantee this race?
> >>
> >>Thanks for pointing out this. It sounds reasonable. However, this
> >>should be only possible to happen on 32 bit since just 32 bit
> >>version page_is_idle() calls lookup_page_ext(), it doesn't do it on
> >>64 bit.
> >>
> >>And, such race condition should exist regardless of whether DEBUG_VM
> >>is enabled or not, right?
> >>
> >>rcu might be good enough to protect it.
> >>
> >>A quick fix may look like:
> >>
> >>diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> >>index 8f5d4ad..bf0cd6a 100644
> >>--- a/include/linux/page_idle.h
> >>+++ b/include/linux/page_idle.h
> >>@@ -77,8 +77,12 @@ static inline bool
> >>test_and_clear_page_young(struct page *page)
> >> static inline bool page_is_idle(struct page *page)
> >> {
> >>struct page_ext *page_ext;
> >>+
> >>+   rcu_read_lock();
> >>page_ext = lookup_page_ext(page);
> >>+   rcu_read_unlock();
> >>+
> >>if (unlikely(!page_ext))
> >>return false;
> >>
> >>diff --git a/mm/page_ext.c b/mm/page_ext.c
> >>index 56b160f..94927c9 100644
> >>--- a/mm/page_ext.c
> >>+++ b/mm/page_ext.c
> >>@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
> >> {
> >>unsigned long pfn = page_to_pfn(page);
> >>struct mem_section *section = __pfn_to_section(pfn);
> >>-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
> >>/*
> >> * The sanity checks the page allocator does upon freeing a
> >> * page can reach here before the page_ext arrays are
> >>@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
> >> */
> >>if (!section->page_ext)
> >>return NULL;
> >>-#endif
> >>+
> >>return section->page_ext + pfn;
> >> }
> >>
> >>@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
> >>return;
> >>base = ms->page_ext + pfn;
> >>free_page_ext(base);
> >>-   ms->page_ext = NULL;
> >>+   rcu_assign_pointer(ms->page_ext, NULL);
> >>+   synchronize_rcu();
> >
> >How does it fix the problem?
> >I cannot understand your point.
> 
> Assigning NULL pointer to page_Ext will be blocked until
> rcu_read_lock critical section is done, so the lookup and writing
> operations will be serialized. And, rcu_read_lock disables preempt
> too.

I meant your rcu_read_lock in page_idle should cover test_bit op.
One more thing, you should use rcu_dereference.

As well, please cover memory onlining case I mentioned in another
thread as well as memory offlining.

Anyway, to me, every caller of page_ext should prepare lookup_page_ext
can return NULL anytime and they should use rcu_read_[un]lock, which
is not good. :(

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Minchan Kim 
On Wed, Jun 01, 2016 at 01:40:48PM -0700, Shi, Yang wrote:
> On 5/29/2016 11:11 PM, Minchan Kim wrote:
> >On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:
> >
> >
> >
> >>>
> >>>If we goes this way, how to guarantee this race?
> >>
> >>Thanks for pointing out this. It sounds reasonable. However, this
> >>should be only possible to happen on 32 bit since just 32 bit
> >>version page_is_idle() calls lookup_page_ext(), it doesn't do it on
> >>64 bit.
> >>
> >>And, such race condition should exist regardless of whether DEBUG_VM
> >>is enabled or not, right?
> >>
> >>rcu might be good enough to protect it.
> >>
> >>A quick fix may look like:
> >>
> >>diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> >>index 8f5d4ad..bf0cd6a 100644
> >>--- a/include/linux/page_idle.h
> >>+++ b/include/linux/page_idle.h
> >>@@ -77,8 +77,12 @@ static inline bool
> >>test_and_clear_page_young(struct page *page)
> >> static inline bool page_is_idle(struct page *page)
> >> {
> >>struct page_ext *page_ext;
> >>+
> >>+   rcu_read_lock();
> >>page_ext = lookup_page_ext(page);
> >>+   rcu_read_unlock();
> >>+
> >>if (unlikely(!page_ext))
> >>return false;
> >>
> >>diff --git a/mm/page_ext.c b/mm/page_ext.c
> >>index 56b160f..94927c9 100644
> >>--- a/mm/page_ext.c
> >>+++ b/mm/page_ext.c
> >>@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
> >> {
> >>unsigned long pfn = page_to_pfn(page);
> >>struct mem_section *section = __pfn_to_section(pfn);
> >>-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
> >>/*
> >> * The sanity checks the page allocator does upon freeing a
> >> * page can reach here before the page_ext arrays are
> >>@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
> >> */
> >>if (!section->page_ext)
> >>return NULL;
> >>-#endif
> >>+
> >>return section->page_ext + pfn;
> >> }
> >>
> >>@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
> >>return;
> >>base = ms->page_ext + pfn;
> >>free_page_ext(base);
> >>-   ms->page_ext = NULL;
> >>+   rcu_assign_pointer(ms->page_ext, NULL);
> >>+   synchronize_rcu();
> >
> >How does it fix the problem?
> >I cannot understand your point.
> 
> Assigning NULL pointer to page_Ext will be blocked until
> rcu_read_lock critical section is done, so the lookup and writing
> operations will be serialized. And, rcu_read_lock disables preempt
> too.

I meant your rcu_read_lock in page_idle should cover test_bit op.
One more thing, you should use rcu_dereference.

As well, please cover memory onlining case I mentioned in another
thread as well as memory offlining.

Anyway, to me, every caller of page_ext should prepare lookup_page_ext
can return NULL anytime and they should use rcu_read_[un]lock, which
is not good. :(

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Shi, Yang 

On 5/29/2016 11:08 PM, Minchan Kim wrote:

On Mon, May 30, 2016 at 02:39:06PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:

On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.


Hello, Minchan.


Hi Joonsoo,



I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?


I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.


There is no detail so I can't guess how to use it and how it causes
the serious problem. But, we can do it when it is really needed.



My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.


If there is no drawback, it would be a better design. But, we have
trade-off that for some case that the memory is added but not
onlined, there is memory saving if we allocate page_ext later.
So, in current situation that there is no user to require such
guarantee, I don't think it's worth doing right now.


However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.


Agreed.


Okay, We realized from this discussion that by design, guest of page_ext
at the meoment should know his page_ext access from the page can be failed
so every caller should prepare for it.

Shi, Yang, Please include some comment about that in your patch to
prevent further reviewer waste his time with repeating same discussion
and client of page_ext can know the limitation.




My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.


Yes, your suggestion would be good for future direction, but, for now,
I think that inserting NULL to all callers is right fix.

1) Current design that page_ext is allocated when online is design
decision of page_ext to save memory as much as possible. Fixing
possible problem within this design decision looks good to me.


Okay. Shi Yang, please include this comment in your patch, too.


There is already such comment in lookup_page_ext:

 * The sanity checks the page allocator does upon freeing a
 * page can reach here before the page_ext arrays are
 * allocated when feeding a range of pages to the allocator
 * for the first time during bootup or memory hotplug.

I will add more details, i.e. newly added but not onlined memory could 
reach here too.






2) Maybe, we need to backport fixes because it would crash older
kernels. In this case, fix with NULL is easy to backport.


Agreed.

Then, Shi Yang need to mark the page as stable.


Agreed.


Shi, Please resend your patch with hard testing and more better
description with marking it as stable.


Will come with an incremental patch to remove CONFIG_DEBUG #ifdef and 
fix the improve the comments since the comments are included by it.


Thanks,
Yang


And I know another race problem about Shi's patch.
I will reply to the thread.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Shi, Yang 

On 5/29/2016 11:08 PM, Minchan Kim wrote:

On Mon, May 30, 2016 at 02:39:06PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:

On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.


Hello, Minchan.


Hi Joonsoo,



I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?


I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.


There is no detail so I can't guess how to use it and how it causes
the serious problem. But, we can do it when it is really needed.



My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.


If there is no drawback, it would be a better design. But, we have
trade-off that for some case that the memory is added but not
onlined, there is memory saving if we allocate page_ext later.
So, in current situation that there is no user to require such
guarantee, I don't think it's worth doing right now.


However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.


Agreed.


Okay, We realized from this discussion that by design, guest of page_ext
at the meoment should know his page_ext access from the page can be failed
so every caller should prepare for it.

Shi, Yang, Please include some comment about that in your patch to
prevent further reviewer waste his time with repeating same discussion
and client of page_ext can know the limitation.




My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.


Yes, your suggestion would be good for future direction, but, for now,
I think that inserting NULL to all callers is right fix.

1) Current design that page_ext is allocated when online is design
decision of page_ext to save memory as much as possible. Fixing
possible problem within this design decision looks good to me.


Okay. Shi Yang, please include this comment in your patch, too.


There is already such comment in lookup_page_ext:

 * The sanity checks the page allocator does upon freeing a
 * page can reach here before the page_ext arrays are
 * allocated when feeding a range of pages to the allocator
 * for the first time during bootup or memory hotplug.

I will add more details, i.e. newly added but not onlined memory could 
reach here too.






2) Maybe, we need to backport fixes because it would crash older
kernels. In this case, fix with NULL is easy to backport.


Agreed.

Then, Shi Yang need to mark the page as stable.


Agreed.


Shi, Please resend your patch with hard testing and more better
description with marking it as stable.


Will come with an incremental patch to remove CONFIG_DEBUG #ifdef and 
fix the improve the comments since the comments are included by it.


Thanks,
Yang


And I know another race problem about Shi's patch.
I will reply to the thread.








And, allocation such

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Shi, Yang 

On 5/29/2016 11:11 PM, Minchan Kim wrote:

On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:





If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this
should be only possible to happen on 32 bit since just 32 bit
version page_is_idle() calls lookup_page_ext(), it doesn't do it on
64 bit.

And, such race condition should exist regardless of whether DEBUG_VM
is enabled or not, right?

rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index 8f5d4ad..bf0cd6a 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -77,8 +77,12 @@ static inline bool
test_and_clear_page_young(struct page *page)
 static inline bool page_is_idle(struct page *page)
 {
struct page_ext *page_ext;
+
+   rcu_read_lock();
page_ext = lookup_page_ext(page);
+   rcu_read_unlock();
+
if (unlikely(!page_ext))
return false;

diff --git a/mm/page_ext.c b/mm/page_ext.c
index 56b160f..94927c9 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
 {
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
/*
 * The sanity checks the page allocator does upon freeing a
 * page can reach here before the page_ext arrays are
@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
 */
if (!section->page_ext)
return NULL;
-#endif
+
return section->page_ext + pfn;
 }

@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
return;
base = ms->page_ext + pfn;
free_page_ext(base);
-   ms->page_ext = NULL;
+   rcu_assign_pointer(ms->page_ext, NULL);
+   synchronize_rcu();


How does it fix the problem?
I cannot understand your point.


Assigning NULL pointer to page_Ext will be blocked until rcu_read_lock 
critical section is done, so the lookup and writing operations will be 
serialized. And, rcu_read_lock disables preempt too.


Yang




 }

 static int __meminit online_page_ext(unsigned long start_pfn,

Thanks,
Yang



   kpageflags_read
   stable_page_flags
   page_is_idle
 lookup_page_ext
 section = __pfn_to_section(pfn)
offline_pages
memory_notify(MEM_OFFLINE)
 offline_page_ext
 ms->page_ext = NULL
 section->page_ext + pfn



Thanks.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-06-01 Thread Shi, Yang 

On 5/29/2016 11:11 PM, Minchan Kim wrote:

On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:





If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this
should be only possible to happen on 32 bit since just 32 bit
version page_is_idle() calls lookup_page_ext(), it doesn't do it on
64 bit.

And, such race condition should exist regardless of whether DEBUG_VM
is enabled or not, right?

rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index 8f5d4ad..bf0cd6a 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -77,8 +77,12 @@ static inline bool
test_and_clear_page_young(struct page *page)
 static inline bool page_is_idle(struct page *page)
 {
struct page_ext *page_ext;
+
+   rcu_read_lock();
page_ext = lookup_page_ext(page);
+   rcu_read_unlock();
+
if (unlikely(!page_ext))
return false;

diff --git a/mm/page_ext.c b/mm/page_ext.c
index 56b160f..94927c9 100644
--- a/mm/page_ext.c
+++ b/mm/page_ext.c
@@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
 {
unsigned long pfn = page_to_pfn(page);
struct mem_section *section = __pfn_to_section(pfn);
-#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
/*
 * The sanity checks the page allocator does upon freeing a
 * page can reach here before the page_ext arrays are
@@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
 */
if (!section->page_ext)
return NULL;
-#endif
+
return section->page_ext + pfn;
 }

@@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
return;
base = ms->page_ext + pfn;
free_page_ext(base);
-   ms->page_ext = NULL;
+   rcu_assign_pointer(ms->page_ext, NULL);
+   synchronize_rcu();


How does it fix the problem?
I cannot understand your point.


Assigning NULL pointer to page_Ext will be blocked until rcu_read_lock 
critical section is done, so the lookup and writing operations will be 
serialized. And, rcu_read_lock disables preempt too.


Yang




 }

 static int __meminit online_page_ext(unsigned long start_pfn,

Thanks,
Yang



   kpageflags_read
   stable_page_flags
   page_is_idle
 lookup_page_ext
 section = __pfn_to_section(pfn)
offline_pages
memory_notify(MEM_OFFLINE)
 offline_page_ext
 ms->page_ext = NULL
 section->page_ext + pfn



Thanks.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> Per the discussion with Joonsoo Kim [1], we need check the return value of
> lookup_page_ext() for all call sites since it might return NULL in some cases,
> although it is unlikely, i.e. memory hotplug.
> 
> Tested with ltp with "page_owner=0".
> 
> [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> 
> Signed-off-by: Yang Shi 
> ---
>  include/linux/page_idle.h | 43 ---
>  mm/page_alloc.c   |  6 ++
>  mm/page_owner.c   | 27 +++
>  mm/page_poison.c  |  8 +++-
>  mm/vmstat.c   |  2 ++
>  5 files changed, 78 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index bf268fa..8f5d4ad 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
>  
>  static inline bool page_is_young(struct page *page)
>  {
> - return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline void set_page_young(struct page *page)
>  {
> - set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool test_and_clear_page_young(struct page *page)
>  {
> - return test_and_clear_bit(PAGE_EXT_YOUNG,
> -   _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool page_is_idle(struct page *page)
>  {
> - return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void set_page_idle(struct page *page)
>  {
> - set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void clear_page_idle(struct page *page)
>  {
> - clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + clear_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  #endif /* CONFIG_64BIT */
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8f3bfc..d27e8b9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   INIT_LIST_HEAD(>lru);
> @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   set_page_private(page, 0);
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 792b56d..902e398 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  
>   for (i = 0; i < (1 << order); i++) {
>   page_ext = lookup_page_ext(page + i);
> + if (unlikely(!page_ext))
> + continue;
>   __clear_bit(PAGE_EXT_OWNER, _ext->flags);
>   }
>  }
> @@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
>  {
>   struct page_ext *page_ext = lookup_page_ext(page);
> +
> + if (unlikely(!page_ext))
> + return;
> +
>   struct stack_trace trace = {
>   .nr_entries = 0,
>   .max_entries = ARRAY_SIZE(page_ext->trace_entries),
> @@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int 
> order, gfp_t gfp_mask)
>  void __set_page_owner_migrate_reason(struct page *page, int reason)
>  {
>   struct page_ext *page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
>  
>

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> Per the discussion with Joonsoo Kim [1], we need check the return value of
> lookup_page_ext() for all call sites since it might return NULL in some cases,
> although it is unlikely, i.e. memory hotplug.
> 
> Tested with ltp with "page_owner=0".
> 
> [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> 
> Signed-off-by: Yang Shi 
> ---
>  include/linux/page_idle.h | 43 ---
>  mm/page_alloc.c   |  6 ++
>  mm/page_owner.c   | 27 +++
>  mm/page_poison.c  |  8 +++-
>  mm/vmstat.c   |  2 ++
>  5 files changed, 78 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index bf268fa..8f5d4ad 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
>  
>  static inline bool page_is_young(struct page *page)
>  {
> - return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline void set_page_young(struct page *page)
>  {
> - set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool test_and_clear_page_young(struct page *page)
>  {
> - return test_and_clear_bit(PAGE_EXT_YOUNG,
> -   _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool page_is_idle(struct page *page)
>  {
> - return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void set_page_idle(struct page *page)
>  {
> - set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void clear_page_idle(struct page *page)
>  {
> - clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + clear_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  #endif /* CONFIG_64BIT */
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8f3bfc..d27e8b9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   INIT_LIST_HEAD(>lru);
> @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   set_page_private(page, 0);
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 792b56d..902e398 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  
>   for (i = 0; i < (1 << order); i++) {
>   page_ext = lookup_page_ext(page + i);
> + if (unlikely(!page_ext))
> + continue;
>   __clear_bit(PAGE_EXT_OWNER, _ext->flags);
>   }
>  }
> @@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
>  {
>   struct page_ext *page_ext = lookup_page_ext(page);
> +
> + if (unlikely(!page_ext))
> + return;
> +
>   struct stack_trace trace = {
>   .nr_entries = 0,
>   .max_entries = ARRAY_SIZE(page_ext->trace_entries),
> @@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int 
> order, gfp_t gfp_mask)
>  void __set_page_owner_migrate_reason(struct page *page, int reason)
>  {
>   struct page_ext *page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
>  
>   page_ext->last_migrate_reason =

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:



> >
> >If we goes this way, how to guarantee this race?
> 
> Thanks for pointing out this. It sounds reasonable. However, this
> should be only possible to happen on 32 bit since just 32 bit
> version page_is_idle() calls lookup_page_ext(), it doesn't do it on
> 64 bit.
> 
> And, such race condition should exist regardless of whether DEBUG_VM
> is enabled or not, right?
> 
> rcu might be good enough to protect it.
> 
> A quick fix may look like:
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index 8f5d4ad..bf0cd6a 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -77,8 +77,12 @@ static inline bool
> test_and_clear_page_young(struct page *page)
>  static inline bool page_is_idle(struct page *page)
>  {
> struct page_ext *page_ext;
> +
> +   rcu_read_lock();
> page_ext = lookup_page_ext(page);
> +   rcu_read_unlock();
> +
>   if (unlikely(!page_ext))
> return false;
> 
> diff --git a/mm/page_ext.c b/mm/page_ext.c
> index 56b160f..94927c9 100644
> --- a/mm/page_ext.c
> +++ b/mm/page_ext.c
> @@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
>  {
> unsigned long pfn = page_to_pfn(page);
> struct mem_section *section = __pfn_to_section(pfn);
> -#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
> /*
>  * The sanity checks the page allocator does upon freeing a
>  * page can reach here before the page_ext arrays are
> @@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
>  */
> if (!section->page_ext)
> return NULL;
> -#endif
> +
> return section->page_ext + pfn;
>  }
> 
> @@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
> return;
> base = ms->page_ext + pfn;
> free_page_ext(base);
> -   ms->page_ext = NULL;
> +   rcu_assign_pointer(ms->page_ext, NULL);
> +   synchronize_rcu();

How does it fix the problem?
I cannot understand your point.

>  }
> 
>  static int __meminit online_page_ext(unsigned long start_pfn,
> 
> Thanks,
> Yang
> 
> >
> >kpageflags_read
> >stable_page_flags
> >page_is_idle
> >  lookup_page_ext
> >  section = __pfn_to_section(pfn)
> >offline_pages
> >memory_notify(MEM_OFFLINE)
> >  offline_page_ext
> >  ms->page_ext = NULL
> >  section->page_ext + pfn
> >
> >>
> >>Thanks.
> >>
>

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Fri, May 27, 2016 at 11:16:41AM -0700, Shi, Yang wrote:



> >
> >If we goes this way, how to guarantee this race?
> 
> Thanks for pointing out this. It sounds reasonable. However, this
> should be only possible to happen on 32 bit since just 32 bit
> version page_is_idle() calls lookup_page_ext(), it doesn't do it on
> 64 bit.
> 
> And, such race condition should exist regardless of whether DEBUG_VM
> is enabled or not, right?
> 
> rcu might be good enough to protect it.
> 
> A quick fix may look like:
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index 8f5d4ad..bf0cd6a 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -77,8 +77,12 @@ static inline bool
> test_and_clear_page_young(struct page *page)
>  static inline bool page_is_idle(struct page *page)
>  {
> struct page_ext *page_ext;
> +
> +   rcu_read_lock();
> page_ext = lookup_page_ext(page);
> +   rcu_read_unlock();
> +
>   if (unlikely(!page_ext))
> return false;
> 
> diff --git a/mm/page_ext.c b/mm/page_ext.c
> index 56b160f..94927c9 100644
> --- a/mm/page_ext.c
> +++ b/mm/page_ext.c
> @@ -183,7 +183,6 @@ struct page_ext *lookup_page_ext(struct page *page)
>  {
> unsigned long pfn = page_to_pfn(page);
> struct mem_section *section = __pfn_to_section(pfn);
> -#if defined(CONFIG_DEBUG_VM) || defined(CONFIG_PAGE_POISONING)
> /*
>  * The sanity checks the page allocator does upon freeing a
>  * page can reach here before the page_ext arrays are
> @@ -195,7 +194,7 @@ struct page_ext *lookup_page_ext(struct page *page)
>  */
> if (!section->page_ext)
> return NULL;
> -#endif
> +
> return section->page_ext + pfn;
>  }
> 
> @@ -279,7 +278,8 @@ static void __free_page_ext(unsigned long pfn)
> return;
> base = ms->page_ext + pfn;
> free_page_ext(base);
> -   ms->page_ext = NULL;
> +   rcu_assign_pointer(ms->page_ext, NULL);
> +   synchronize_rcu();

How does it fix the problem?
I cannot understand your point.

>  }
> 
>  static int __meminit online_page_ext(unsigned long start_pfn,
> 
> Thanks,
> Yang
> 
> >
> >kpageflags_read
> >stable_page_flags
> >page_is_idle
> >  lookup_page_ext
> >  section = __pfn_to_section(pfn)
> >offline_pages
> >memory_notify(MEM_OFFLINE)
> >  offline_page_ext
> >  ms->page_ext = NULL
> >  section->page_ext + pfn
> >
> >>
> >>Thanks.
> >>
>

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Mon, May 30, 2016 at 02:39:06PM +0900, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:
> > On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> > > On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > > > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > > > >>>value of
> > > > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > > > >>>some cases,
> > > > > >>>although it is unlikely, i.e. memory hotplug.
> > > > > >>>
> > > > > >>>Tested with ltp with "page_owner=0".
> > > > > >>>
> > > > > >>>[1] 
> > > > > >>>http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > > > >>>
> > > > > >>>Signed-off-by: Yang Shi 
> > > > > >>
> > > > > >>I didn't read code code in detail to see how page_ext memory space
> > > > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > > > >>to check NULL whenever we calls lookup_page_ext.
> > > > > >>
> > > > > >>More dangerous thing is now page_ext is used by optionable 
> > > > > >>feature(ie, not
> > > > > >>critical for system stability) but if we want to use page_ext as
> > > > > >>another important tool for the system in future,
> > > > > >>it could be a serious problem.
> > > 
> > > Hello, Minchan.
> > 
> > Hi Joonsoo,
> > 
> > > 
> > > I wonder how pages that isn't managed by kernel yet will cause serious
> > > problem. Until onlining, these pages are out of our scope. Any
> > > information about them would be useless until it is actually
> > > activated. I guess that returning NULL for those pages will not hurt
> > > any functionality. Do you have any possible scenario that this causes the
> > > serious problem?
> > 
> > I don't have any specific usecase now. That's why I said "in future".
> > And I don't want to argue whether there is possible scenario or not
> > to make the feature useful but if you want, I should write novel.
> > One of example, pop up my mind, xen, hv and even memory_hotplug itself
> > might want to use page_ext for their functionality extension to hook
> > guest pages.
> 
> There is no detail so I can't guess how to use it and how it causes
> the serious problem. But, we can do it when it is really needed.
> 
> > 
> > My opinion is that page_ext is extension of struct page so it would
> > be better to allow any operation on struct page without any limitation
> > if we can do it. Whether it's useful or useless depend on random
> > usecase and we don't need to limit that way from the beginning.
> 
> If there is no drawback, it would be a better design. But, we have
> trade-off that for some case that the memory is added but not
> onlined, there is memory saving if we allocate page_ext later.
> So, in current situation that there is no user to require such
> guarantee, I don't think it's worth doing right now.
> 
> > However, current design allows deferred page_ext population so any user
> > of page_ext should keep it in mind and should either make fallback plan
> > or don't use page_ext for those cases. If we decide go this way through
> > discussion, at least, we should make such limitation more clear to
> > somewhere in this chance, maybe around page_ext_operation->need comment.
> 
> Agreed.

Okay, We realized from this discussion that by design, guest of page_ext
at the meoment should know his page_ext access from the page can be failed
so every caller should prepare for it.

Shi, Yang, Please include some comment about that in your patch to
prevent further reviewer waste his time with repeating same discussion
and client of page_ext can know the limitation.

> 
> > My comment's point is that we should consider that way at least. It's
> > worth to discuss pros and cons, what's the best and what makes that way
> > hesitate if we can't.
> 
> Yes, your suggestion would be good for future direction, but, for now,
> I think that inserting NULL to all callers is right fix.
> 
> 1) Current design that page_ext is allocated when online is design
> decision of page_ext to save memory as much as possible. Fixing
> possible problem within this design decision looks good to me.

Okay. Shi Yang, please include this comment in your patch, too.

> 
> 2) Maybe, we need to backport fixes because it would crash older
> kernels. In this case, fix with NULL is easy to backport.

Agreed.

Then, Shi Yang need to mark the page as stable.
Shi, Please resend your patch with hard testing and more better
description with marking it as stable.
And I know another race problem about Shi's patch.
I will reply to the thread.

> 
> > > 
> > > And, allocation such memory space doesn't come from free. If someone
> > > just add the memory device and don't

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-30 Thread Minchan Kim 
On Mon, May 30, 2016 at 02:39:06PM +0900, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:
> > On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> > > On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > > > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > > > >>>value of
> > > > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > > > >>>some cases,
> > > > > >>>although it is unlikely, i.e. memory hotplug.
> > > > > >>>
> > > > > >>>Tested with ltp with "page_owner=0".
> > > > > >>>
> > > > > >>>[1] 
> > > > > >>>http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > > > >>>
> > > > > >>>Signed-off-by: Yang Shi 
> > > > > >>
> > > > > >>I didn't read code code in detail to see how page_ext memory space
> > > > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > > > >>to check NULL whenever we calls lookup_page_ext.
> > > > > >>
> > > > > >>More dangerous thing is now page_ext is used by optionable 
> > > > > >>feature(ie, not
> > > > > >>critical for system stability) but if we want to use page_ext as
> > > > > >>another important tool for the system in future,
> > > > > >>it could be a serious problem.
> > > 
> > > Hello, Minchan.
> > 
> > Hi Joonsoo,
> > 
> > > 
> > > I wonder how pages that isn't managed by kernel yet will cause serious
> > > problem. Until onlining, these pages are out of our scope. Any
> > > information about them would be useless until it is actually
> > > activated. I guess that returning NULL for those pages will not hurt
> > > any functionality. Do you have any possible scenario that this causes the
> > > serious problem?
> > 
> > I don't have any specific usecase now. That's why I said "in future".
> > And I don't want to argue whether there is possible scenario or not
> > to make the feature useful but if you want, I should write novel.
> > One of example, pop up my mind, xen, hv and even memory_hotplug itself
> > might want to use page_ext for their functionality extension to hook
> > guest pages.
> 
> There is no detail so I can't guess how to use it and how it causes
> the serious problem. But, we can do it when it is really needed.
> 
> > 
> > My opinion is that page_ext is extension of struct page so it would
> > be better to allow any operation on struct page without any limitation
> > if we can do it. Whether it's useful or useless depend on random
> > usecase and we don't need to limit that way from the beginning.
> 
> If there is no drawback, it would be a better design. But, we have
> trade-off that for some case that the memory is added but not
> onlined, there is memory saving if we allocate page_ext later.
> So, in current situation that there is no user to require such
> guarantee, I don't think it's worth doing right now.
> 
> > However, current design allows deferred page_ext population so any user
> > of page_ext should keep it in mind and should either make fallback plan
> > or don't use page_ext for those cases. If we decide go this way through
> > discussion, at least, we should make such limitation more clear to
> > somewhere in this chance, maybe around page_ext_operation->need comment.
> 
> Agreed.

Okay, We realized from this discussion that by design, guest of page_ext
at the meoment should know his page_ext access from the page can be failed
so every caller should prepare for it.

Shi, Yang, Please include some comment about that in your patch to
prevent further reviewer waste his time with repeating same discussion
and client of page_ext can know the limitation.

> 
> > My comment's point is that we should consider that way at least. It's
> > worth to discuss pros and cons, what's the best and what makes that way
> > hesitate if we can't.
> 
> Yes, your suggestion would be good for future direction, but, for now,
> I think that inserting NULL to all callers is right fix.
> 
> 1) Current design that page_ext is allocated when online is design
> decision of page_ext to save memory as much as possible. Fixing
> possible problem within this design decision looks good to me.

Okay. Shi Yang, please include this comment in your patch, too.

> 
> 2) Maybe, we need to backport fixes because it would crash older
> kernels. In this case, fix with NULL is easy to backport.

Agreed.

Then, Shi Yang need to mark the page as stable.
Shi, Please resend your patch with hard testing and more better
description with marking it as stable.
And I know another race problem about Shi's patch.
I will reply to the thread.

> 
> > > 
> > > And, allocation such memory space doesn't come from free. If someone
> > > just add the memory device and don't online it, these

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-29 Thread Joonsoo Kim 
On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:
> On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> > On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > > >>>value of
> > > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > > >>>some cases,
> > > > >>>although it is unlikely, i.e. memory hotplug.
> > > > >>>
> > > > >>>Tested with ltp with "page_owner=0".
> > > > >>>
> > > > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > > >>>
> > > > >>>Signed-off-by: Yang Shi 
> > > > >>
> > > > >>I didn't read code code in detail to see how page_ext memory space
> > > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > > >>to check NULL whenever we calls lookup_page_ext.
> > > > >>
> > > > >>More dangerous thing is now page_ext is used by optionable 
> > > > >>feature(ie, not
> > > > >>critical for system stability) but if we want to use page_ext as
> > > > >>another important tool for the system in future,
> > > > >>it could be a serious problem.
> > 
> > Hello, Minchan.
> 
> Hi Joonsoo,
> 
> > 
> > I wonder how pages that isn't managed by kernel yet will cause serious
> > problem. Until onlining, these pages are out of our scope. Any
> > information about them would be useless until it is actually
> > activated. I guess that returning NULL for those pages will not hurt
> > any functionality. Do you have any possible scenario that this causes the
> > serious problem?
> 
> I don't have any specific usecase now. That's why I said "in future".
> And I don't want to argue whether there is possible scenario or not
> to make the feature useful but if you want, I should write novel.
> One of example, pop up my mind, xen, hv and even memory_hotplug itself
> might want to use page_ext for their functionality extension to hook
> guest pages.

There is no detail so I can't guess how to use it and how it causes
the serious problem. But, we can do it when it is really needed.

> 
> My opinion is that page_ext is extension of struct page so it would
> be better to allow any operation on struct page without any limitation
> if we can do it. Whether it's useful or useless depend on random
> usecase and we don't need to limit that way from the beginning.

If there is no drawback, it would be a better design. But, we have
trade-off that for some case that the memory is added but not
onlined, there is memory saving if we allocate page_ext later.
So, in current situation that there is no user to require such
guarantee, I don't think it's worth doing right now.

> However, current design allows deferred page_ext population so any user
> of page_ext should keep it in mind and should either make fallback plan
> or don't use page_ext for those cases. If we decide go this way through
> discussion, at least, we should make such limitation more clear to
> somewhere in this chance, maybe around page_ext_operation->need comment.

Agreed.

> My comment's point is that we should consider that way at least. It's
> worth to discuss pros and cons, what's the best and what makes that way
> hesitate if we can't.

Yes, your suggestion would be good for future direction, but, for now,
I think that inserting NULL to all callers is right fix.

1) Current design that page_ext is allocated when online is design
decision of page_ext to save memory as much as possible. Fixing
possible problem within this design decision looks good to me.

2) Maybe, we need to backport fixes because it would crash older
kernels. In this case, fix with NULL is easy to backport.

> > 
> > And, allocation such memory space doesn't come from free. If someone
> > just add the memory device and don't online it, these memory will be
> 
> Here goes several questions.
> Cced hotplug guys
> 
> 1.
> If someone just add the memory device without onlining, kernel code
> can return pfn_valid == true on the offlined page?

AFAIK, yes.
> 
> 2.
> If so, it means memmap on offline memory is already populated somewhere.
> Where is the memmap allocated? part of offlined memory space or other memory?

Other memory.

> 3. Could we allocate page_ext in part of offline memory space so that
> it doesn't consume online memory.
> 
> > wasted. I don't know if there is such a usecase but it's possible
> > scenario.
> 
> > 
> > > > >>
> > > > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > > > >>that page_ext memory space is allocated with memmap space at the
> > > > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > > > >>is valid, too so lookup_page_ext never returns NULL on valid page
> >

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-29 Thread Joonsoo Kim 
On Fri, May 27, 2016 at 05:11:08PM +0900, Minchan Kim wrote:
> On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> > On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > > >>>value of
> > > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > > >>>some cases,
> > > > >>>although it is unlikely, i.e. memory hotplug.
> > > > >>>
> > > > >>>Tested with ltp with "page_owner=0".
> > > > >>>
> > > > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > > >>>
> > > > >>>Signed-off-by: Yang Shi 
> > > > >>
> > > > >>I didn't read code code in detail to see how page_ext memory space
> > > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > > >>to check NULL whenever we calls lookup_page_ext.
> > > > >>
> > > > >>More dangerous thing is now page_ext is used by optionable 
> > > > >>feature(ie, not
> > > > >>critical for system stability) but if we want to use page_ext as
> > > > >>another important tool for the system in future,
> > > > >>it could be a serious problem.
> > 
> > Hello, Minchan.
> 
> Hi Joonsoo,
> 
> > 
> > I wonder how pages that isn't managed by kernel yet will cause serious
> > problem. Until onlining, these pages are out of our scope. Any
> > information about them would be useless until it is actually
> > activated. I guess that returning NULL for those pages will not hurt
> > any functionality. Do you have any possible scenario that this causes the
> > serious problem?
> 
> I don't have any specific usecase now. That's why I said "in future".
> And I don't want to argue whether there is possible scenario or not
> to make the feature useful but if you want, I should write novel.
> One of example, pop up my mind, xen, hv and even memory_hotplug itself
> might want to use page_ext for their functionality extension to hook
> guest pages.

There is no detail so I can't guess how to use it and how it causes
the serious problem. But, we can do it when it is really needed.

> 
> My opinion is that page_ext is extension of struct page so it would
> be better to allow any operation on struct page without any limitation
> if we can do it. Whether it's useful or useless depend on random
> usecase and we don't need to limit that way from the beginning.

If there is no drawback, it would be a better design. But, we have
trade-off that for some case that the memory is added but not
onlined, there is memory saving if we allocate page_ext later.
So, in current situation that there is no user to require such
guarantee, I don't think it's worth doing right now.

> However, current design allows deferred page_ext population so any user
> of page_ext should keep it in mind and should either make fallback plan
> or don't use page_ext for those cases. If we decide go this way through
> discussion, at least, we should make such limitation more clear to
> somewhere in this chance, maybe around page_ext_operation->need comment.

Agreed.

> My comment's point is that we should consider that way at least. It's
> worth to discuss pros and cons, what's the best and what makes that way
> hesitate if we can't.

Yes, your suggestion would be good for future direction, but, for now,
I think that inserting NULL to all callers is right fix.

1) Current design that page_ext is allocated when online is design
decision of page_ext to save memory as much as possible. Fixing
possible problem within this design decision looks good to me.

2) Maybe, we need to backport fixes because it would crash older
kernels. In this case, fix with NULL is easy to backport.

> > 
> > And, allocation such memory space doesn't come from free. If someone
> > just add the memory device and don't online it, these memory will be
> 
> Here goes several questions.
> Cced hotplug guys
> 
> 1.
> If someone just add the memory device without onlining, kernel code
> can return pfn_valid == true on the offlined page?

AFAIK, yes.
> 
> 2.
> If so, it means memmap on offline memory is already populated somewhere.
> Where is the memmap allocated? part of offlined memory space or other memory?

Other memory.

> 3. Could we allocate page_ext in part of offline memory space so that
> it doesn't consume online memory.
> 
> > wasted. I don't know if there is such a usecase but it's possible
> > scenario.
> 
> > 
> > > > >>
> > > > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > > > >>that page_ext memory space is allocated with memmap space at the
> > > > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > > > >>is valid, too so lookup_page_ext never returns NULL on valid page
> > > > >>by design.
> >

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Andrew Morton 
On Fri, 27 May 2016 13:17:19 -0700 "Shi, Yang"  wrote:

> >> Actually, I think the #ifdef should be removed if lookup_page_ext() is
> >> possible to return NULL. It sounds not make sense returning NULL only
> >> when DEBUG_VM is enabled. It should return NULL no matter what debug
> >> config is selected. If Joonsoo agrees with me I'm going to come up with
> >> a patch to fix it.
> >>
> >
> > I've lost the plot here.  What is the status of this patch?
> >
> > Latest version:
> 
> Yes, this is the latest version. We are discussing about some future 
> optimization.
> 
> And, Minchan Kim pointed out a possible race condition which exists even 
> before this patch. I proposed a quick fix, as long as they are happy to 
> the fix, I will post it to the mailing list.

OK, thanks - I've moved it into the for-Linus-next-week queue.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Andrew Morton 
On Fri, 27 May 2016 13:17:19 -0700 "Shi, Yang"  wrote:

> >> Actually, I think the #ifdef should be removed if lookup_page_ext() is
> >> possible to return NULL. It sounds not make sense returning NULL only
> >> when DEBUG_VM is enabled. It should return NULL no matter what debug
> >> config is selected. If Joonsoo agrees with me I'm going to come up with
> >> a patch to fix it.
> >>
> >
> > I've lost the plot here.  What is the status of this patch?
> >
> > Latest version:
> 
> Yes, this is the latest version. We are discussing about some future 
> optimization.
> 
> And, Minchan Kim pointed out a possible race condition which exists even 
> before this patch. I proposed a quick fix, as long as they are happy to 
> the fix, I will post it to the mailing list.

OK, thanks - I've moved it into the for-Linus-next-week queue.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Shi, Yang 

On 5/27/2016 1:02 PM, Andrew Morton wrote:

On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang"  wrote:



I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was busy on
preparing patches. I do agree this is a direction we should look into,
but I haven't got time to think about it deeper. I hope Joonsoo could
chime in too since he is the original author for page extension.



Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext() is
possible to return NULL. It sounds not make sense returning NULL only
when DEBUG_VM is enabled. It should return NULL no matter what debug
config is selected. If Joonsoo agrees with me I'm going to come up with
a patch to fix it.



I've lost the plot here.  What is the status of this patch?

Latest version:


Yes, this is the latest version. We are discussing about some future 
optimization.


And, Minchan Kim pointed out a possible race condition which exists even 
before this patch. I proposed a quick fix, as long as they are happy to 
the fix, I will post it to the mailing list.


Thanks,
Yang



From: Yang Shi 
Subject: mm: check the return value of lookup_page_ext for all call sites

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some
cases, although it is unlikely, i.e.  memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

[a...@linux-foundation.org: fix build-breaking typos]
[a...@arndb.de: fix build problems from lookup_page_ext]
  Link: http://lkml.kernel.org/r/6285269.2CksypHdYp@wuerfel
[a...@linux-foundation.org: coding-style fixes]
Link: 
http://lkml.kernel.org/r/1464023768-31025-1-git-send-email-yang@linaro.org
Signed-off-by: Yang Shi 
Signed-off-by: Arnd Bergmann 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
---

 include/linux/page_idle.h |   43 ++--
 mm/page_alloc.c   |6 +
 mm/page_owner.c   |   26 +
 mm/page_poison.c  |8 +-
 mm/vmstat.c   |2 +
 5 files changed, 77 insertions(+), 8 deletions(-)

diff -puN 
include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
 include/linux/page_idle.h
--- 
a/include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_i

 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */

diff -puN 
mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites 
mm/page_alloc.c
--- 
a/mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Shi, Yang 

On 5/27/2016 1:02 PM, Andrew Morton wrote:

On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang"  wrote:



I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was busy on
preparing patches. I do agree this is a direction we should look into,
but I haven't got time to think about it deeper. I hope Joonsoo could
chime in too since he is the original author for page extension.



Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext() is
possible to return NULL. It sounds not make sense returning NULL only
when DEBUG_VM is enabled. It should return NULL no matter what debug
config is selected. If Joonsoo agrees with me I'm going to come up with
a patch to fix it.



I've lost the plot here.  What is the status of this patch?

Latest version:


Yes, this is the latest version. We are discussing about some future 
optimization.


And, Minchan Kim pointed out a possible race condition which exists even 
before this patch. I proposed a quick fix, as long as they are happy to 
the fix, I will post it to the mailing list.


Thanks,
Yang



From: Yang Shi 
Subject: mm: check the return value of lookup_page_ext for all call sites

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some
cases, although it is unlikely, i.e.  memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

[a...@linux-foundation.org: fix build-breaking typos]
[a...@arndb.de: fix build problems from lookup_page_ext]
  Link: http://lkml.kernel.org/r/6285269.2CksypHdYp@wuerfel
[a...@linux-foundation.org: coding-style fixes]
Link: 
http://lkml.kernel.org/r/1464023768-31025-1-git-send-email-yang@linaro.org
Signed-off-by: Yang Shi 
Signed-off-by: Arnd Bergmann 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
---

 include/linux/page_idle.h |   43 ++--
 mm/page_alloc.c   |6 +
 mm/page_owner.c   |   26 +
 mm/page_poison.c  |8 +-
 mm/vmstat.c   |2 +
 5 files changed, 77 insertions(+), 8 deletions(-)

diff -puN 
include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
 include/linux/page_idle.h
--- 
a/include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_i

 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */

diff -puN 
mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites 
mm/page_alloc.c
--- 
a/mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct
return;

page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Andrew Morton 
On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang"  wrote:

> >>
> >> I hope we consider this direction, too.
> >
> > Yang, Could you think about this?
> 
> Thanks a lot for the suggestion. Sorry for the late reply, I was busy on 
> preparing patches. I do agree this is a direction we should look into, 
> but I haven't got time to think about it deeper. I hope Joonsoo could 
> chime in too since he is the original author for page extension.
> 
> >
> > Even, your patch was broken, I think.
> > It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > lookup_page_ext doesn't return NULL in that case.
> 
> Actually, I think the #ifdef should be removed if lookup_page_ext() is 
> possible to return NULL. It sounds not make sense returning NULL only 
> when DEBUG_VM is enabled. It should return NULL no matter what debug 
> config is selected. If Joonsoo agrees with me I'm going to come up with 
> a patch to fix it.
> 

I've lost the plot here.  What is the status of this patch?

Latest version:

From: Yang Shi 
Subject: mm: check the return value of lookup_page_ext for all call sites

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some
cases, although it is unlikely, i.e.  memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

[a...@linux-foundation.org: fix build-breaking typos]
[a...@arndb.de: fix build problems from lookup_page_ext]
  Link: http://lkml.kernel.org/r/6285269.2CksypHdYp@wuerfel
[a...@linux-foundation.org: coding-style fixes]
Link: 
http://lkml.kernel.org/r/1464023768-31025-1-git-send-email-yang@linaro.org
Signed-off-by: Yang Shi 
Signed-off-by: Arnd Bergmann 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
---

 include/linux/page_idle.h |   43 ++--
 mm/page_alloc.c   |6 +
 mm/page_owner.c   |   26 +
 mm/page_poison.c  |8 +-
 mm/vmstat.c   |2 +
 5 files changed, 77 insertions(+), 8 deletions(-)

diff -puN 
include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
 include/linux/page_idle.h
--- 
a/include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_i
 
 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */
 
diff -puN 
mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites 
mm/page_alloc.c
--- 
a/mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@ static inline void clear_page_guard(stru

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Andrew Morton 
On Thu, 26 May 2016 16:15:28 -0700 "Shi, Yang"  wrote:

> >>
> >> I hope we consider this direction, too.
> >
> > Yang, Could you think about this?
> 
> Thanks a lot for the suggestion. Sorry for the late reply, I was busy on 
> preparing patches. I do agree this is a direction we should look into, 
> but I haven't got time to think about it deeper. I hope Joonsoo could 
> chime in too since he is the original author for page extension.
> 
> >
> > Even, your patch was broken, I think.
> > It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > lookup_page_ext doesn't return NULL in that case.
> 
> Actually, I think the #ifdef should be removed if lookup_page_ext() is 
> possible to return NULL. It sounds not make sense returning NULL only 
> when DEBUG_VM is enabled. It should return NULL no matter what debug 
> config is selected. If Joonsoo agrees with me I'm going to come up with 
> a patch to fix it.
> 

I've lost the plot here.  What is the status of this patch?

Latest version:

From: Yang Shi 
Subject: mm: check the return value of lookup_page_ext for all call sites

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some
cases, although it is unlikely, i.e.  memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

[a...@linux-foundation.org: fix build-breaking typos]
[a...@arndb.de: fix build problems from lookup_page_ext]
  Link: http://lkml.kernel.org/r/6285269.2CksypHdYp@wuerfel
[a...@linux-foundation.org: coding-style fixes]
Link: 
http://lkml.kernel.org/r/1464023768-31025-1-git-send-email-yang@linaro.org
Signed-off-by: Yang Shi 
Signed-off-by: Arnd Bergmann 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
---

 include/linux/page_idle.h |   43 ++--
 mm/page_alloc.c   |6 +
 mm/page_owner.c   |   26 +
 mm/page_poison.c  |8 +-
 mm/vmstat.c   |2 +
 5 files changed, 77 insertions(+), 8 deletions(-)

diff -puN 
include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
 include/linux/page_idle.h
--- 
a/include/linux/page_idle.h~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_i
 
 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */
 
diff -puN 
mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites 
mm/page_alloc.c
--- 
a/mm/page_alloc.c~mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites
+++ a/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@ static inline void clear_page_guard(stru
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Shi, Yang 

On 5/27/2016 1:11 AM, Minchan Kim wrote:

On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.


Hello, Minchan.


Hi Joonsoo,



I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?


I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.

My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.

However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.

My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.



And, allocation such memory space doesn't come from free. If someone
just add the memory device and don't online it, these memory will be


Here goes several questions.
Cced hotplug guys

1.
If someone just add the memory device without onlining, kernel code
can return pfn_valid == true on the offlined page?

2.
If so, it means memmap on offline memory is already populated somewhere.
Where is the memmap allocated? part of offlined memory space or other memory?

3. Could we allocate page_ext in part of offline memory space so that
it doesn't consume online memory.


wasted. I don't know if there is such a usecase but it's possible
scenario.






Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was
busy on preparing patches. I do agree this is a direction we should
look into, but I haven't got time to think about it deeper. I hope
Joonsoo could chime in too since he is the original author for page
extension.



Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext()
is possible to return NULL. It sounds not make sense returning NULL
only when DEBUG_VM is enabled. It should return NULL no matter what
debug config is selected. If Joonsoo agrees with me I'm going to
come up with a patch to fix it.


Agreed but let's wait for Minchan's response.


If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this should 
be only possible to happen on 32 bit since just 32 bit version 
page_is_idle() calls lookup_page_ext(), it doesn't do it on 64 bit.


And, such race condition should exist regardless of whether DEBUG_VM is 
enabled or not, right?


rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Shi, Yang 

On 5/27/2016 1:11 AM, Minchan Kim wrote:

On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:

On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:

On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.


Hello, Minchan.


Hi Joonsoo,



I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?


I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.

My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.

However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.

My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.



And, allocation such memory space doesn't come from free. If someone
just add the memory device and don't online it, these memory will be


Here goes several questions.
Cced hotplug guys

1.
If someone just add the memory device without onlining, kernel code
can return pfn_valid == true on the offlined page?

2.
If so, it means memmap on offline memory is already populated somewhere.
Where is the memmap allocated? part of offlined memory space or other memory?

3. Could we allocate page_ext in part of offline memory space so that
it doesn't consume online memory.


wasted. I don't know if there is such a usecase but it's possible
scenario.






Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was
busy on preparing patches. I do agree this is a direction we should
look into, but I haven't got time to think about it deeper. I hope
Joonsoo could chime in too since he is the original author for page
extension.



Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext()
is possible to return NULL. It sounds not make sense returning NULL
only when DEBUG_VM is enabled. It should return NULL no matter what
debug config is selected. If Joonsoo agrees with me I'm going to
come up with a patch to fix it.


Agreed but let's wait for Minchan's response.


If we goes this way, how to guarantee this race?


Thanks for pointing out this. It sounds reasonable. However, this should 
be only possible to happen on 32 bit since just 32 bit version 
page_is_idle() calls lookup_page_ext(), it doesn't do it on 64 bit.


And, such race condition should exist regardless of whether DEBUG_VM is 
enabled or not, right?


rcu might be good enough to protect it.

A quick fix may look like:

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index 8f5d4ad..bf0cd6a

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Minchan Kim 
On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > >>>value of
> > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > >>>some cases,
> > > >>>although it is unlikely, i.e. memory hotplug.
> > > >>>
> > > >>>Tested with ltp with "page_owner=0".
> > > >>>
> > > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > >>>
> > > >>>Signed-off-by: Yang Shi 
> > > >>
> > > >>I didn't read code code in detail to see how page_ext memory space
> > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > >>to check NULL whenever we calls lookup_page_ext.
> > > >>
> > > >>More dangerous thing is now page_ext is used by optionable feature(ie, 
> > > >>not
> > > >>critical for system stability) but if we want to use page_ext as
> > > >>another important tool for the system in future,
> > > >>it could be a serious problem.
> 
> Hello, Minchan.

Hi Joonsoo,

> 
> I wonder how pages that isn't managed by kernel yet will cause serious
> problem. Until onlining, these pages are out of our scope. Any
> information about them would be useless until it is actually
> activated. I guess that returning NULL for those pages will not hurt
> any functionality. Do you have any possible scenario that this causes the
> serious problem?

I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.

My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.

However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.

My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.

> 
> And, allocation such memory space doesn't come from free. If someone
> just add the memory device and don't online it, these memory will be

Here goes several questions.
Cced hotplug guys

1.
If someone just add the memory device without onlining, kernel code
can return pfn_valid == true on the offlined page?

2.
If so, it means memmap on offline memory is already populated somewhere.
Where is the memmap allocated? part of offlined memory space or other memory?

3. Could we allocate page_ext in part of offline memory space so that
it doesn't consume online memory.

> wasted. I don't know if there is such a usecase but it's possible
> scenario.

> 
> > > >>
> > > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > > >>that page_ext memory space is allocated with memmap space at the
> > > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > > >>is valid, too so lookup_page_ext never returns NULL on valid page
> > > >>by design.
> > > >>
> > > >>I hope we consider this direction, too.
> > > >
> > > >Yang, Could you think about this?
> > > 
> > > Thanks a lot for the suggestion. Sorry for the late reply, I was
> > > busy on preparing patches. I do agree this is a direction we should
> > > look into, but I haven't got time to think about it deeper. I hope
> > > Joonsoo could chime in too since he is the original author for page
> > > extension.
> > > 
> > > >
> > > >Even, your patch was broken, I think.
> > > >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > > >lookup_page_ext doesn't return NULL in that case.
> > > 
> > > Actually, I think the #ifdef should be removed if lookup_page_ext()
> > > is possible to return NULL. It sounds not make sense returning NULL
> > > only when DEBUG_VM is enabled. It should return NULL no matter what
> > > debug config is selected. If Joonsoo agrees with me I'm going to
> > > come up with a patch to fix it.
> 
> Agreed but let's wait for Minchan's response.

If we goes this way, how to guarantee this race?

kpageflags_read

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Minchan Kim 
On Fri, May 27, 2016 at 03:08:39PM +0900, Joonsoo Kim wrote:
> On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> > On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > > >>>Per the discussion with Joonsoo Kim [1], we need check the return 
> > > >>>value of
> > > >>>lookup_page_ext() for all call sites since it might return NULL in 
> > > >>>some cases,
> > > >>>although it is unlikely, i.e. memory hotplug.
> > > >>>
> > > >>>Tested with ltp with "page_owner=0".
> > > >>>
> > > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > > >>>
> > > >>>Signed-off-by: Yang Shi 
> > > >>
> > > >>I didn't read code code in detail to see how page_ext memory space
> > > >>allocated in boot code and memory hotplug but to me, it's not good
> > > >>to check NULL whenever we calls lookup_page_ext.
> > > >>
> > > >>More dangerous thing is now page_ext is used by optionable feature(ie, 
> > > >>not
> > > >>critical for system stability) but if we want to use page_ext as
> > > >>another important tool for the system in future,
> > > >>it could be a serious problem.
> 
> Hello, Minchan.

Hi Joonsoo,

> 
> I wonder how pages that isn't managed by kernel yet will cause serious
> problem. Until onlining, these pages are out of our scope. Any
> information about them would be useless until it is actually
> activated. I guess that returning NULL for those pages will not hurt
> any functionality. Do you have any possible scenario that this causes the
> serious problem?

I don't have any specific usecase now. That's why I said "in future".
And I don't want to argue whether there is possible scenario or not
to make the feature useful but if you want, I should write novel.
One of example, pop up my mind, xen, hv and even memory_hotplug itself
might want to use page_ext for their functionality extension to hook
guest pages.

My opinion is that page_ext is extension of struct page so it would
be better to allow any operation on struct page without any limitation
if we can do it. Whether it's useful or useless depend on random
usecase and we don't need to limit that way from the beginning.

However, current design allows deferred page_ext population so any user
of page_ext should keep it in mind and should either make fallback plan
or don't use page_ext for those cases. If we decide go this way through
discussion, at least, we should make such limitation more clear to
somewhere in this chance, maybe around page_ext_operation->need comment.

My comment's point is that we should consider that way at least. It's
worth to discuss pros and cons, what's the best and what makes that way
hesitate if we can't.

> 
> And, allocation such memory space doesn't come from free. If someone
> just add the memory device and don't online it, these memory will be

Here goes several questions.
Cced hotplug guys

1.
If someone just add the memory device without onlining, kernel code
can return pfn_valid == true on the offlined page?

2.
If so, it means memmap on offline memory is already populated somewhere.
Where is the memmap allocated? part of offlined memory space or other memory?

3. Could we allocate page_ext in part of offline memory space so that
it doesn't consume online memory.

> wasted. I don't know if there is such a usecase but it's possible
> scenario.

> 
> > > >>
> > > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > > >>that page_ext memory space is allocated with memmap space at the
> > > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > > >>is valid, too so lookup_page_ext never returns NULL on valid page
> > > >>by design.
> > > >>
> > > >>I hope we consider this direction, too.
> > > >
> > > >Yang, Could you think about this?
> > > 
> > > Thanks a lot for the suggestion. Sorry for the late reply, I was
> > > busy on preparing patches. I do agree this is a direction we should
> > > look into, but I haven't got time to think about it deeper. I hope
> > > Joonsoo could chime in too since he is the original author for page
> > > extension.
> > > 
> > > >
> > > >Even, your patch was broken, I think.
> > > >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > > >lookup_page_ext doesn't return NULL in that case.
> > > 
> > > Actually, I think the #ifdef should be removed if lookup_page_ext()
> > > is possible to return NULL. It sounds not make sense returning NULL
> > > only when DEBUG_VM is enabled. It should return NULL no matter what
> > > debug config is selected. If Joonsoo agrees with me I'm going to
> > > come up with a patch to fix it.
> 
> Agreed but let's wait for Minchan's response.

If we goes this way, how to guarantee this race?

kpageflags_read
stable_page_flags

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Joonsoo Kim 
On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > >>>Per the discussion with Joonsoo Kim [1], we need check the return value 
> > >>>of
> > >>>lookup_page_ext() for all call sites since it might return NULL in some 
> > >>>cases,
> > >>>although it is unlikely, i.e. memory hotplug.
> > >>>
> > >>>Tested with ltp with "page_owner=0".
> > >>>
> > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > >>>
> > >>>Signed-off-by: Yang Shi 
> > >>
> > >>I didn't read code code in detail to see how page_ext memory space
> > >>allocated in boot code and memory hotplug but to me, it's not good
> > >>to check NULL whenever we calls lookup_page_ext.
> > >>
> > >>More dangerous thing is now page_ext is used by optionable feature(ie, not
> > >>critical for system stability) but if we want to use page_ext as
> > >>another important tool for the system in future,
> > >>it could be a serious problem.

Hello, Minchan.

I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?

And, allocation such memory space doesn't come from free. If someone
just add the memory device and don't online it, these memory will be
wasted. I don't know if there is such a usecase but it's possible
scenario.

> > >>
> > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > >>that page_ext memory space is allocated with memmap space at the
> > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > >>is valid, too so lookup_page_ext never returns NULL on valid page
> > >>by design.
> > >>
> > >>I hope we consider this direction, too.
> > >
> > >Yang, Could you think about this?
> > 
> > Thanks a lot for the suggestion. Sorry for the late reply, I was
> > busy on preparing patches. I do agree this is a direction we should
> > look into, but I haven't got time to think about it deeper. I hope
> > Joonsoo could chime in too since he is the original author for page
> > extension.
> > 
> > >
> > >Even, your patch was broken, I think.
> > >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > >lookup_page_ext doesn't return NULL in that case.
> > 
> > Actually, I think the #ifdef should be removed if lookup_page_ext()
> > is possible to return NULL. It sounds not make sense returning NULL
> > only when DEBUG_VM is enabled. It should return NULL no matter what
> > debug config is selected. If Joonsoo agrees with me I'm going to
> > come up with a patch to fix it.

Agreed but let's wait for Minchan's response.

Thanks.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-27 Thread Joonsoo Kim 
On Fri, May 27, 2016 at 02:14:32PM +0900, Minchan Kim wrote:
> On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> > On 5/25/2016 5:37 PM, Minchan Kim wrote:
> > >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> > >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > >>>Per the discussion with Joonsoo Kim [1], we need check the return value 
> > >>>of
> > >>>lookup_page_ext() for all call sites since it might return NULL in some 
> > >>>cases,
> > >>>although it is unlikely, i.e. memory hotplug.
> > >>>
> > >>>Tested with ltp with "page_owner=0".
> > >>>
> > >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > >>>
> > >>>Signed-off-by: Yang Shi 
> > >>
> > >>I didn't read code code in detail to see how page_ext memory space
> > >>allocated in boot code and memory hotplug but to me, it's not good
> > >>to check NULL whenever we calls lookup_page_ext.
> > >>
> > >>More dangerous thing is now page_ext is used by optionable feature(ie, not
> > >>critical for system stability) but if we want to use page_ext as
> > >>another important tool for the system in future,
> > >>it could be a serious problem.

Hello, Minchan.

I wonder how pages that isn't managed by kernel yet will cause serious
problem. Until onlining, these pages are out of our scope. Any
information about them would be useless until it is actually
activated. I guess that returning NULL for those pages will not hurt
any functionality. Do you have any possible scenario that this causes the
serious problem?

And, allocation such memory space doesn't come from free. If someone
just add the memory device and don't online it, these memory will be
wasted. I don't know if there is such a usecase but it's possible
scenario.

> > >>
> > >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> > >>that page_ext memory space is allocated with memmap space at the
> > >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> > >>is valid, too so lookup_page_ext never returns NULL on valid page
> > >>by design.
> > >>
> > >>I hope we consider this direction, too.
> > >
> > >Yang, Could you think about this?
> > 
> > Thanks a lot for the suggestion. Sorry for the late reply, I was
> > busy on preparing patches. I do agree this is a direction we should
> > look into, but I haven't got time to think about it deeper. I hope
> > Joonsoo could chime in too since he is the original author for page
> > extension.
> > 
> > >
> > >Even, your patch was broken, I think.
> > >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> > >lookup_page_ext doesn't return NULL in that case.
> > 
> > Actually, I think the #ifdef should be removed if lookup_page_ext()
> > is possible to return NULL. It sounds not make sense returning NULL
> > only when DEBUG_VM is enabled. It should return NULL no matter what
> > debug config is selected. If Joonsoo agrees with me I'm going to
> > come up with a patch to fix it.

Agreed but let's wait for Minchan's response.

Thanks.

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-26 Thread Minchan Kim 
On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> On 5/25/2016 5:37 PM, Minchan Kim wrote:
> >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> >>>Per the discussion with Joonsoo Kim [1], we need check the return value of
> >>>lookup_page_ext() for all call sites since it might return NULL in some 
> >>>cases,
> >>>although it is unlikely, i.e. memory hotplug.
> >>>
> >>>Tested with ltp with "page_owner=0".
> >>>
> >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> >>>
> >>>Signed-off-by: Yang Shi 
> >>
> >>I didn't read code code in detail to see how page_ext memory space
> >>allocated in boot code and memory hotplug but to me, it's not good
> >>to check NULL whenever we calls lookup_page_ext.
> >>
> >>More dangerous thing is now page_ext is used by optionable feature(ie, not
> >>critical for system stability) but if we want to use page_ext as
> >>another important tool for the system in future,
> >>it could be a serious problem.
> >>
> >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> >>that page_ext memory space is allocated with memmap space at the
> >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> >>is valid, too so lookup_page_ext never returns NULL on valid page
> >>by design.
> >>
> >>I hope we consider this direction, too.
> >
> >Yang, Could you think about this?
> 
> Thanks a lot for the suggestion. Sorry for the late reply, I was
> busy on preparing patches. I do agree this is a direction we should
> look into, but I haven't got time to think about it deeper. I hope
> Joonsoo could chime in too since he is the original author for page
> extension.
> 
> >
> >Even, your patch was broken, I think.
> >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> >lookup_page_ext doesn't return NULL in that case.
> 
> Actually, I think the #ifdef should be removed if lookup_page_ext()
> is possible to return NULL. It sounds not make sense returning NULL
> only when DEBUG_VM is enabled. It should return NULL no matter what
> debug config is selected. If Joonsoo agrees with me I'm going to
> come up with a patch to fix it.

I don't know what lock protects race section->page_ext storing/tearing
during memory hotplug while random thread accesses pege_ext,
for example, kpageflags->page_is_idle.

Please consider that, too if you want to go with this approach.

> 
> Regards,
> Yang
> 
> >
> >>
> >>Thanks.
> >>
> >>>---
> >>> include/linux/page_idle.h | 43 ---
> >>> mm/page_alloc.c   |  6 ++
> >>> mm/page_owner.c   | 27 +++
> >>> mm/page_poison.c  |  8 +++-
> >>> mm/vmstat.c   |  2 ++
> >>> 5 files changed, 78 insertions(+), 8 deletions(-)
> >>>
> >>>diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> >>>index bf268fa..8f5d4ad 100644
> >>>--- a/include/linux/page_idle.h
> >>>+++ b/include/linux/page_idle.h
> >>>@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
> >>>
> >>> static inline bool page_is_young(struct page *page)
> >>> {
> >>>-  return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline void set_page_young(struct page *page)
> >>> {
> >>>-  set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return;
> >>>+
> >>>+  set_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline bool test_and_clear_page_young(struct page *page)
> >>> {
> >>>-  return test_and_clear_bit(PAGE_EXT_YOUNG,
> >>>-_page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline bool page_is_idle(struct page *page)
> >>> {
> >>>-  return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_bit(PAGE_EXT_IDLE, _ext->flags);
> >>> }
> >>>
> >>> static inline void set_page_idle(struct page *page)
> >>> {
> >>>-  set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return;
> >>>+
> >>>+  set_bit(PAGE_EXT_IDLE, _ext->flags);
> >>> }
> >>>
> >>> static inline void clear_page_idle(struct page *page)
> >>> {
> >>>-  clear_bit(PAGE_EXT_IDLE,

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-26 Thread Minchan Kim 
On Thu, May 26, 2016 at 04:15:28PM -0700, Shi, Yang wrote:
> On 5/25/2016 5:37 PM, Minchan Kim wrote:
> >On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> >>On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> >>>Per the discussion with Joonsoo Kim [1], we need check the return value of
> >>>lookup_page_ext() for all call sites since it might return NULL in some 
> >>>cases,
> >>>although it is unlikely, i.e. memory hotplug.
> >>>
> >>>Tested with ltp with "page_owner=0".
> >>>
> >>>[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> >>>
> >>>Signed-off-by: Yang Shi 
> >>
> >>I didn't read code code in detail to see how page_ext memory space
> >>allocated in boot code and memory hotplug but to me, it's not good
> >>to check NULL whenever we calls lookup_page_ext.
> >>
> >>More dangerous thing is now page_ext is used by optionable feature(ie, not
> >>critical for system stability) but if we want to use page_ext as
> >>another important tool for the system in future,
> >>it could be a serious problem.
> >>
> >>Can we put some hooks of page_ext into memory-hotplug so guarantee
> >>that page_ext memory space is allocated with memmap space at the
> >>same time? IOW, once every PFN wakers find a page is valid, page_ext
> >>is valid, too so lookup_page_ext never returns NULL on valid page
> >>by design.
> >>
> >>I hope we consider this direction, too.
> >
> >Yang, Could you think about this?
> 
> Thanks a lot for the suggestion. Sorry for the late reply, I was
> busy on preparing patches. I do agree this is a direction we should
> look into, but I haven't got time to think about it deeper. I hope
> Joonsoo could chime in too since he is the original author for page
> extension.
> 
> >
> >Even, your patch was broken, I think.
> >It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
> >lookup_page_ext doesn't return NULL in that case.
> 
> Actually, I think the #ifdef should be removed if lookup_page_ext()
> is possible to return NULL. It sounds not make sense returning NULL
> only when DEBUG_VM is enabled. It should return NULL no matter what
> debug config is selected. If Joonsoo agrees with me I'm going to
> come up with a patch to fix it.

I don't know what lock protects race section->page_ext storing/tearing
during memory hotplug while random thread accesses pege_ext,
for example, kpageflags->page_is_idle.

Please consider that, too if you want to go with this approach.

> 
> Regards,
> Yang
> 
> >
> >>
> >>Thanks.
> >>
> >>>---
> >>> include/linux/page_idle.h | 43 ---
> >>> mm/page_alloc.c   |  6 ++
> >>> mm/page_owner.c   | 27 +++
> >>> mm/page_poison.c  |  8 +++-
> >>> mm/vmstat.c   |  2 ++
> >>> 5 files changed, 78 insertions(+), 8 deletions(-)
> >>>
> >>>diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> >>>index bf268fa..8f5d4ad 100644
> >>>--- a/include/linux/page_idle.h
> >>>+++ b/include/linux/page_idle.h
> >>>@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
> >>>
> >>> static inline bool page_is_young(struct page *page)
> >>> {
> >>>-  return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline void set_page_young(struct page *page)
> >>> {
> >>>-  set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return;
> >>>+
> >>>+  set_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline bool test_and_clear_page_young(struct page *page)
> >>> {
> >>>-  return test_and_clear_bit(PAGE_EXT_YOUNG,
> >>>-_page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
> >>> }
> >>>
> >>> static inline bool page_is_idle(struct page *page)
> >>> {
> >>>-  return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return false;
> >>>+
> >>>+  return test_bit(PAGE_EXT_IDLE, _ext->flags);
> >>> }
> >>>
> >>> static inline void set_page_idle(struct page *page)
> >>> {
> >>>-  set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> >>>+  struct page_ext *page_ext;
> >>>+  page_ext = lookup_page_ext(page);
> >>>+  if (unlikely(!page_ext)
> >>>+  return;
> >>>+
> >>>+  set_bit(PAGE_EXT_IDLE, _ext->flags);
> >>> }
> >>>
> >>> static inline void clear_page_idle(struct page *page)
> >>> {
> >>>-  clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
>

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-26 Thread Shi, Yang 

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.

Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was busy on 
preparing patches. I do agree this is a direction we should look into, 
but I haven't got time to think about it deeper. I hope Joonsoo could 
chime in too since he is the original author for page extension.




Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext() is 
possible to return NULL. It sounds not make sense returning NULL only 
when DEBUG_VM is enabled. It should return NULL no matter what debug 
config is selected. If Joonsoo agrees with me I'm going to come up with 
a patch to fix it.


Regards,
Yang





Thanks.


---
 include/linux/page_idle.h | 43 ---
 mm/page_alloc.c   |  6 ++
 mm/page_owner.c   | 27 +++
 mm/page_poison.c  |  8 +++-
 mm/vmstat.c   |  2 ++
 5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;

 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;

page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);

INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-26 Thread Shi, Yang 

On 5/25/2016 5:37 PM, Minchan Kim wrote:

On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:

On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 


I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.

Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.


Yang, Could you think about this?


Thanks a lot for the suggestion. Sorry for the late reply, I was busy on 
preparing patches. I do agree this is a direction we should look into, 
but I haven't got time to think about it deeper. I hope Joonsoo could 
chime in too since he is the original author for page extension.




Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.


Actually, I think the #ifdef should be removed if lookup_page_ext() is 
possible to return NULL. It sounds not make sense returning NULL only 
when DEBUG_VM is enabled. It should return NULL no matter what debug 
config is selected. If Joonsoo agrees with me I'm going to come up with 
a patch to fix it.


Regards,
Yang





Thanks.


---
 include/linux/page_idle.h | 43 ---
 mm/page_alloc.c   |  6 ++
 mm/page_owner.c   | 27 +++
 mm/page_poison.c  |  8 +++-
 mm/vmstat.c   |  2 ++
 5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;

 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }

 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }

 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;

page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);

INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@ static inline void

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-25 Thread Minchan Kim 
On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > Per the discussion with Joonsoo Kim [1], we need check the return value of
> > lookup_page_ext() for all call sites since it might return NULL in some 
> > cases,
> > although it is unlikely, i.e. memory hotplug.
> > 
> > Tested with ltp with "page_owner=0".
> > 
> > [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > 
> > Signed-off-by: Yang Shi 
> 
> I didn't read code code in detail to see how page_ext memory space
> allocated in boot code and memory hotplug but to me, it's not good
> to check NULL whenever we calls lookup_page_ext.
> 
> More dangerous thing is now page_ext is used by optionable feature(ie, not
> critical for system stability) but if we want to use page_ext as
> another important tool for the system in future,
> it could be a serious problem.
> 
> Can we put some hooks of page_ext into memory-hotplug so guarantee
> that page_ext memory space is allocated with memmap space at the
> same time? IOW, once every PFN wakers find a page is valid, page_ext
> is valid, too so lookup_page_ext never returns NULL on valid page
> by design.
> 
> I hope we consider this direction, too.

Yang, Could you think about this?

Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.

> 
> Thanks.
> 
> > ---
> >  include/linux/page_idle.h | 43 ---
> >  mm/page_alloc.c   |  6 ++
> >  mm/page_owner.c   | 27 +++
> >  mm/page_poison.c  |  8 +++-
> >  mm/vmstat.c   |  2 ++
> >  5 files changed, 78 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> > index bf268fa..8f5d4ad 100644
> > --- a/include/linux/page_idle.h
> > +++ b/include/linux/page_idle.h
> > @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
> >  
> >  static inline bool page_is_young(struct page *page)
> >  {
> > -   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline void set_page_young(struct page *page)
> >  {
> > -   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   set_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline bool test_and_clear_page_young(struct page *page)
> >  {
> > -   return test_and_clear_bit(PAGE_EXT_YOUNG,
> > - _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline bool page_is_idle(struct page *page)
> >  {
> > -   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  
> >  static inline void set_page_idle(struct page *page)
> >  {
> > -   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   set_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  
> >  static inline void clear_page_idle(struct page *page)
> >  {
> > -   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   clear_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  #endif /* CONFIG_64BIT */
> >  
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index f8f3bfc..d27e8b9 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> > struct page *page,
> > return;
> >  
> > page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext))
> > +   return;
> > +
> > __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
> >  
> > INIT_LIST_HEAD(>lru);
> > @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> > struct page *page,
> > return;
> >  
> > page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext))
> > +   return;
> > +
> > __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
> >  
> > set_page_private(page, 0);
> > diff --git a/mm/page_owner.c

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-25 Thread Minchan Kim 
On Tue, May 24, 2016 at 11:58:11AM +0900, Minchan Kim wrote:
> On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> > Per the discussion with Joonsoo Kim [1], we need check the return value of
> > lookup_page_ext() for all call sites since it might return NULL in some 
> > cases,
> > although it is unlikely, i.e. memory hotplug.
> > 
> > Tested with ltp with "page_owner=0".
> > 
> > [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> > 
> > Signed-off-by: Yang Shi 
> 
> I didn't read code code in detail to see how page_ext memory space
> allocated in boot code and memory hotplug but to me, it's not good
> to check NULL whenever we calls lookup_page_ext.
> 
> More dangerous thing is now page_ext is used by optionable feature(ie, not
> critical for system stability) but if we want to use page_ext as
> another important tool for the system in future,
> it could be a serious problem.
> 
> Can we put some hooks of page_ext into memory-hotplug so guarantee
> that page_ext memory space is allocated with memmap space at the
> same time? IOW, once every PFN wakers find a page is valid, page_ext
> is valid, too so lookup_page_ext never returns NULL on valid page
> by design.
> 
> I hope we consider this direction, too.

Yang, Could you think about this?

Even, your patch was broken, I think.
It doesn't work with !CONFIG_DEBUG_VM && !CONFIG_PAGE_POISONING because
lookup_page_ext doesn't return NULL in that case.

> 
> Thanks.
> 
> > ---
> >  include/linux/page_idle.h | 43 ---
> >  mm/page_alloc.c   |  6 ++
> >  mm/page_owner.c   | 27 +++
> >  mm/page_poison.c  |  8 +++-
> >  mm/vmstat.c   |  2 ++
> >  5 files changed, 78 insertions(+), 8 deletions(-)
> > 
> > diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> > index bf268fa..8f5d4ad 100644
> > --- a/include/linux/page_idle.h
> > +++ b/include/linux/page_idle.h
> > @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
> >  
> >  static inline bool page_is_young(struct page *page)
> >  {
> > -   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline void set_page_young(struct page *page)
> >  {
> > -   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   set_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline bool test_and_clear_page_young(struct page *page)
> >  {
> > -   return test_and_clear_bit(PAGE_EXT_YOUNG,
> > - _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
> >  }
> >  
> >  static inline bool page_is_idle(struct page *page)
> >  {
> > -   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return false;
> > +
> > +   return test_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  
> >  static inline void set_page_idle(struct page *page)
> >  {
> > -   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   set_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  
> >  static inline void clear_page_idle(struct page *page)
> >  {
> > -   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> > +   struct page_ext *page_ext;
> > +   page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext)
> > +   return;
> > +
> > +   clear_bit(PAGE_EXT_IDLE, _ext->flags);
> >  }
> >  #endif /* CONFIG_64BIT */
> >  
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index f8f3bfc..d27e8b9 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> > struct page *page,
> > return;
> >  
> > page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext))
> > +   return;
> > +
> > __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
> >  
> > INIT_LIST_HEAD(>lru);
> > @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> > struct page *page,
> > return;
> >  
> > page_ext = lookup_page_ext(page);
> > +   if (unlikely(!page_ext))
> > +   return;
> > +
> > __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
> >  
> > set_page_private(page, 0);
> > diff --git a/mm/page_owner.c b/mm/page_owner.c
> >

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-25 Thread shakil 



On 5/23/2016 10:16 AM, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 
---
  include/linux/page_idle.h | 43 ---
  mm/page_alloc.c   |  6 ++
  mm/page_owner.c   | 27 +++
  mm/page_poison.c  |  8 +++-
  mm/vmstat.c   |  2 ++
  5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
  
  static inline bool page_is_young(struct page *page)

  {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline void set_page_young(struct page *page)

  {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline bool test_and_clear_page_young(struct page *page)

  {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline bool page_is_idle(struct page *page)

  {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  
  static inline void set_page_idle(struct page *page)

  {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  
  static inline void clear_page_idle(struct page *page)

  {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  #endif /* CONFIG_64BIT */
  
diff --git a/mm/page_alloc.c b/mm/page_alloc.c

index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;
  
  	page_ext = lookup_page_ext(page);

+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
  
  	INIT_LIST_HEAD(>lru);

@@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
struct page *page,
return;
  
  	page_ext = lookup_page_ext(page);

+   if (unlikely(!page_ext))
+   return;
+
__clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
  
  	set_page_private(page, 0);

diff --git a/mm/page_owner.c b/mm/page_owner.c
index 792b56d..902e398 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
  
  	for (i = 0; i < (1 << order); i++) {

page_ext = lookup_page_ext(page + i);
+   if (unlikely(!page_ext))
+   continue;
__clear_bit(PAGE_EXT_OWNER, _ext->flags);
}
  }
@@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
order)
  void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
  {
struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
struct stack_trace trace = {
.nr_entries = 0,
.max_entries = ARRAY_SIZE(page_ext->trace_entries),
@@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int order, 
gfp_t gfp_mask)
  void __set_page_owner_migrate_reason(struct page *page, int reason)
  {
struct page_ext *page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
  
  	page_ext->last_migrate_reason = reason;

  }
@@ -89,6 +97,12 @@ void __set_page_owner_migrate_reason(struct page *page, int 
reason)
  gfp_t __get_page_owner_gfp(struct page

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-25 Thread shakil 



On 5/23/2016 10:16 AM, Yang Shi wrote:

Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 
---
  include/linux/page_idle.h | 43 ---
  mm/page_alloc.c   |  6 ++
  mm/page_owner.c   | 27 +++
  mm/page_poison.c  |  8 +++-
  mm/vmstat.c   |  2 ++
  5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
  
  static inline bool page_is_young(struct page *page)

  {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline void set_page_young(struct page *page)

  {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline bool test_and_clear_page_young(struct page *page)

  {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
  }
  
  static inline bool page_is_idle(struct page *page)

  {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  
  static inline void set_page_idle(struct page *page)

  {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  
  static inline void clear_page_idle(struct page *page)

  {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
  }
  #endif /* CONFIG_64BIT */
  
diff --git a/mm/page_alloc.c b/mm/page_alloc.c

index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;
  
  	page_ext = lookup_page_ext(page);

+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
  
  	INIT_LIST_HEAD(>lru);

@@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
struct page *page,
return;
  
  	page_ext = lookup_page_ext(page);

+   if (unlikely(!page_ext))
+   return;
+
__clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
  
  	set_page_private(page, 0);

diff --git a/mm/page_owner.c b/mm/page_owner.c
index 792b56d..902e398 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
  
  	for (i = 0; i < (1 << order); i++) {

page_ext = lookup_page_ext(page + i);
+   if (unlikely(!page_ext))
+   continue;
__clear_bit(PAGE_EXT_OWNER, _ext->flags);
}
  }
@@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
order)
  void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
  {
struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
struct stack_trace trace = {
.nr_entries = 0,
.max_entries = ARRAY_SIZE(page_ext->trace_entries),
@@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int order, 
gfp_t gfp_mask)
  void __set_page_owner_migrate_reason(struct page *page, int reason)
  {
struct page_ext *page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
  
  	page_ext->last_migrate_reason = reason;

  }
@@ -89,6 +97,12 @@ void __set_page_owner_migrate_reason(struct page *page, int 
reason)
  gfp_t __get_page_owner_gfp(struct page *page)
  {

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-23 Thread Minchan Kim 
On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> Per the discussion with Joonsoo Kim [1], we need check the return value of
> lookup_page_ext() for all call sites since it might return NULL in some cases,
> although it is unlikely, i.e. memory hotplug.
> 
> Tested with ltp with "page_owner=0".
> 
> [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> 
> Signed-off-by: Yang Shi 

I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.

Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.

Thanks.

> ---
>  include/linux/page_idle.h | 43 ---
>  mm/page_alloc.c   |  6 ++
>  mm/page_owner.c   | 27 +++
>  mm/page_poison.c  |  8 +++-
>  mm/vmstat.c   |  2 ++
>  5 files changed, 78 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index bf268fa..8f5d4ad 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
>  
>  static inline bool page_is_young(struct page *page)
>  {
> - return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline void set_page_young(struct page *page)
>  {
> - set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool test_and_clear_page_young(struct page *page)
>  {
> - return test_and_clear_bit(PAGE_EXT_YOUNG,
> -   _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool page_is_idle(struct page *page)
>  {
> - return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void set_page_idle(struct page *page)
>  {
> - set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void clear_page_idle(struct page *page)
>  {
> - clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + clear_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  #endif /* CONFIG_64BIT */
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8f3bfc..d27e8b9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   INIT_LIST_HEAD(>lru);
> @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   set_page_private(page, 0);
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 792b56d..902e398 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  
>   for (i = 0; i < (1 << order); i++) {
>   page_ext = lookup_page_ext(page + i);
> + if (unlikely(!page_ext))
> + continue;
>   __clear_bit(PAGE_EXT_OWNER, _ext->flags);
>   }
>  }
> @@ -62,6

Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-23 Thread Minchan Kim 
On Mon, May 23, 2016 at 10:16:08AM -0700, Yang Shi wrote:
> Per the discussion with Joonsoo Kim [1], we need check the return value of
> lookup_page_ext() for all call sites since it might return NULL in some cases,
> although it is unlikely, i.e. memory hotplug.
> 
> Tested with ltp with "page_owner=0".
> 
> [1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE
> 
> Signed-off-by: Yang Shi 

I didn't read code code in detail to see how page_ext memory space
allocated in boot code and memory hotplug but to me, it's not good
to check NULL whenever we calls lookup_page_ext.

More dangerous thing is now page_ext is used by optionable feature(ie, not
critical for system stability) but if we want to use page_ext as
another important tool for the system in future,
it could be a serious problem.

Can we put some hooks of page_ext into memory-hotplug so guarantee
that page_ext memory space is allocated with memmap space at the
same time? IOW, once every PFN wakers find a page is valid, page_ext
is valid, too so lookup_page_ext never returns NULL on valid page
by design.

I hope we consider this direction, too.

Thanks.

> ---
>  include/linux/page_idle.h | 43 ---
>  mm/page_alloc.c   |  6 ++
>  mm/page_owner.c   | 27 +++
>  mm/page_poison.c  |  8 +++-
>  mm/vmstat.c   |  2 ++
>  5 files changed, 78 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> index bf268fa..8f5d4ad 100644
> --- a/include/linux/page_idle.h
> +++ b/include/linux/page_idle.h
> @@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
>  
>  static inline bool page_is_young(struct page *page)
>  {
> - return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline void set_page_young(struct page *page)
>  {
> - set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool test_and_clear_page_young(struct page *page)
>  {
> - return test_and_clear_bit(PAGE_EXT_YOUNG,
> -   _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
>  }
>  
>  static inline bool page_is_idle(struct page *page)
>  {
> - return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return false;
> +
> + return test_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void set_page_idle(struct page *page)
>  {
> - set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + set_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  
>  static inline void clear_page_idle(struct page *page)
>  {
> - clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
> + struct page_ext *page_ext;
> + page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext)
> + return;
> +
> + clear_bit(PAGE_EXT_IDLE, _ext->flags);
>  }
>  #endif /* CONFIG_64BIT */
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f8f3bfc..d27e8b9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   INIT_LIST_HEAD(>lru);
> @@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
> struct page *page,
>   return;
>  
>   page_ext = lookup_page_ext(page);
> + if (unlikely(!page_ext))
> + return;
> +
>   __clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
>  
>   set_page_private(page, 0);
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 792b56d..902e398 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int 
> order)
>  
>   for (i = 0; i < (1 << order); i++) {
>   page_ext = lookup_page_ext(page + i);
> + if (unlikely(!page_ext))
> + continue;
>   __clear_bit(PAGE_EXT_OWNER, _ext->flags);
>   }
>  }
> @@ -62,6 +64,10 @@ void

[PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-23 Thread Yang Shi 
Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 
---
 include/linux/page_idle.h | 43 ---
 mm/page_alloc.c   |  6 ++
 mm/page_owner.c   | 27 +++
 mm/page_poison.c  |  8 +++-
 mm/vmstat.c   |  2 ++
 5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
 
 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
struct page *page,
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
set_page_private(page, 0);
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 792b56d..902e398 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
 
for (i = 0; i < (1 << order); i++) {
page_ext = lookup_page_ext(page + i);
+   if (unlikely(!page_ext))
+   continue;
__clear_bit(PAGE_EXT_OWNER, _ext->flags);
}
 }
@@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
order)
 void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
struct stack_trace trace = {
.nr_entries = 0,
.max_entries = ARRAY_SIZE(page_ext->trace_entries),
@@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int order, 
gfp_t gfp_mask)
 void __set_page_owner_migrate_reason(struct page *page, int reason)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
 
page_ext->last_migrate_reason = reason;
 }
@@ -89,6 +97,12 @@ void __set_page_owner_migrate_reason(struct page *page, int 
reason)
 gfp_t __get_page_owner_gfp(struct page *page)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+

[PATCH] mm: check the return value of lookup_page_ext for all call sites

2016-05-23 Thread Yang Shi 
Per the discussion with Joonsoo Kim [1], we need check the return value of
lookup_page_ext() for all call sites since it might return NULL in some cases,
although it is unlikely, i.e. memory hotplug.

Tested with ltp with "page_owner=0".

[1] http://lkml.kernel.org/r/20160519002809.GA10245@js1304-P5Q-DELUXE

Signed-off-by: Yang Shi 
---
 include/linux/page_idle.h | 43 ---
 mm/page_alloc.c   |  6 ++
 mm/page_owner.c   | 27 +++
 mm/page_poison.c  |  8 +++-
 mm/vmstat.c   |  2 ++
 5 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
index bf268fa..8f5d4ad 100644
--- a/include/linux/page_idle.h
+++ b/include/linux/page_idle.h
@@ -46,33 +46,62 @@ extern struct page_ext_operations page_idle_ops;
 
 static inline bool page_is_young(struct page *page)
 {
-   return test_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline void set_page_young(struct page *page)
 {
-   set_bit(PAGE_EXT_YOUNG, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool test_and_clear_page_young(struct page *page)
 {
-   return test_and_clear_bit(PAGE_EXT_YOUNG,
- _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_and_clear_bit(PAGE_EXT_YOUNG, _ext->flags);
 }
 
 static inline bool page_is_idle(struct page *page)
 {
-   return test_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return false;
+
+   return test_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void set_page_idle(struct page *page)
 {
-   set_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   set_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 
 static inline void clear_page_idle(struct page *page)
 {
-   clear_bit(PAGE_EXT_IDLE, _page_ext(page)->flags);
+   struct page_ext *page_ext;
+   page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext)
+   return;
+
+   clear_bit(PAGE_EXT_IDLE, _ext->flags);
 }
 #endif /* CONFIG_64BIT */
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f8f3bfc..d27e8b9 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -656,6 +656,9 @@ static inline void set_page_guard(struct zone *zone, struct 
page *page,
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__set_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
INIT_LIST_HEAD(>lru);
@@ -673,6 +676,9 @@ static inline void clear_page_guard(struct zone *zone, 
struct page *page,
return;
 
page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
+
__clear_bit(PAGE_EXT_DEBUG_GUARD, _ext->flags);
 
set_page_private(page, 0);
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 792b56d..902e398 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -55,6 +55,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
 
for (i = 0; i < (1 << order); i++) {
page_ext = lookup_page_ext(page + i);
+   if (unlikely(!page_ext))
+   continue;
__clear_bit(PAGE_EXT_OWNER, _ext->flags);
}
 }
@@ -62,6 +64,10 @@ void __reset_page_owner(struct page *page, unsigned int 
order)
 void __set_page_owner(struct page *page, unsigned int order, gfp_t gfp_mask)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+
+   if (unlikely(!page_ext))
+   return;
+
struct stack_trace trace = {
.nr_entries = 0,
.max_entries = ARRAY_SIZE(page_ext->trace_entries),
@@ -82,6 +88,8 @@ void __set_page_owner(struct page *page, unsigned int order, 
gfp_t gfp_mask)
 void __set_page_owner_migrate_reason(struct page *page, int reason)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+   if (unlikely(!page_ext))
+   return;
 
page_ext->last_migrate_reason = reason;
 }
@@ -89,6 +97,12 @@ void __set_page_owner_migrate_reason(struct page *page, int 
reason)
 gfp_t __get_page_owner_gfp(struct page *page)
 {
struct page_ext *page_ext = lookup_page_ext(page);
+   if