All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: "Shi, Yang" <yang.shi@linaro.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linaro-kernel@lists.linaro.org,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites
Date: Thu, 2 Jun 2016 14:00:39 +0900	[thread overview]
Message-ID: <20160602050039.GA3304@bbox> (raw)
In-Reply-To: <b8858801-af06-9b80-1b29-f9ece515d1bf@linaro.org>

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:
> >
> ><snip>
> >
> >>>
> >>>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. :(

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: "Shi, Yang" <yang.shi@linaro.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>, <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<linaro-kernel@lists.linaro.org>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] mm: check the return value of lookup_page_ext for all call sites
Date: Thu, 2 Jun 2016 14:00:39 +0900	[thread overview]
Message-ID: <20160602050039.GA3304@bbox> (raw)
In-Reply-To: <b8858801-af06-9b80-1b29-f9ece515d1bf@linaro.org>

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:
> >
> ><snip>
> >
> >>>
> >>>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. :(

  reply	other threads:[~2016-06-02  4:59 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 17:16 [PATCH] mm: check the return value of lookup_page_ext for all call sites Yang Shi
2016-05-23 17:16 ` Yang Shi
2016-05-24  2:58 ` Minchan Kim
2016-05-24  2:58   ` Minchan Kim
2016-05-26  0:37   ` Minchan Kim
2016-05-26  0:37     ` Minchan Kim
2016-05-26 23:15     ` Shi, Yang
2016-05-26 23:15       ` Shi, Yang
2016-05-27  5:14       ` Minchan Kim
2016-05-27  5:14         ` Minchan Kim
2016-05-27  6:08         ` Joonsoo Kim
2016-05-27  6:08           ` Joonsoo Kim
2016-05-27  8:11           ` Minchan Kim
2016-05-27  8:11             ` Minchan Kim
2016-05-27 18:16             ` Shi, Yang
2016-05-27 18:16               ` Shi, Yang
2016-05-30  6:11               ` Minchan Kim
2016-05-30  6:11                 ` Minchan Kim
2016-06-01 20:40                 ` Shi, Yang
2016-06-01 20:40                   ` Shi, Yang
2016-06-02  5:00                   ` Minchan Kim [this message]
2016-06-02  5:00                     ` Minchan Kim
2016-06-02 23:15                     ` Shi, Yang
2016-06-02 23:15                       ` Shi, Yang
2016-05-30  5:39             ` Joonsoo Kim
2016-05-30  5:39               ` Joonsoo Kim
2016-05-30  6:08               ` Minchan Kim
2016-05-30  6:08                 ` Minchan Kim
2016-06-01 20:52                 ` Shi, Yang
2016-06-01 20:52                   ` Shi, Yang
2016-05-27 20:02       ` Andrew Morton
2016-05-27 20:02         ` Andrew Morton
2016-05-27 20:17         ` Shi, Yang
2016-05-27 20:17           ` Shi, Yang
2016-05-27 20:30           ` Andrew Morton
2016-05-27 20:30             ` Andrew Morton
2016-05-24 10:08 ` [PATCH] mm: fix build problems from lookup_page_ext Arnd Bergmann
2016-05-24 10:08   ` Arnd Bergmann
2016-05-24 16:33   ` Shi, Yang
2016-05-24 16:33     ` Shi, Yang
2016-05-25  7:12 ` [PATCH] mm: check the return value of lookup_page_ext for all call sites shakil
2016-05-25  7:12   ` shakil
2016-05-30  6:17 ` Minchan Kim
2016-05-30  6:17   ` Minchan Kim
  -- strict thread matches above, loose matches on Subject: below --
2017-11-24  9:28 [PATCH stable-4.4 1/2] " Michal Hocko
2017-11-24  9:30 ` [PATCH] " Michal Hocko
2017-11-24  9:39   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160602050039.GA3304@bbox \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tangchen@cn.fujitsu.com \
    --cc=yang.shi@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.