* [PATCH v2 1/2] mm: free compound page with correct order
@ 2014-10-15 19:20 Yu Zhao
2014-10-15 19:20 ` [PATCH v2 2/2] mm: verify compound order when freeing a page Yu Zhao
2014-10-15 19:30 ` [PATCH v2 1/2] mm: free compound page with correct order Andrew Morton
0 siblings, 2 replies; 6+ messages in thread
From: Yu Zhao @ 2014-10-15 19:20 UTC (permalink / raw)
To: Andrew Morton, Kirill A. Shutemov, Mel Gorman, Rik van Riel,
Ingo Molnar, Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka
Cc: linux-mm, linux-kernel, stable, Yu Zhao
Compound page should be freed by put_page() or free_pages() with
correct order. Not doing so will cause tail pages leaked.
The compound order can be obtained by compound_order() or use
HPAGE_PMD_ORDER in our case. Some people would argue the latter
is faster but I prefer the former which is more general.
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
Cc: stable@vger.kernel.org (v3.8+)
Signed-off-by: Yu Zhao <yuzhao@google.com>
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 74c78aa..780d12c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -200,7 +200,7 @@ retry:
preempt_disable();
if (cmpxchg(&huge_zero_page, NULL, zero_page)) {
preempt_enable();
- __free_page(zero_page);
+ __free_pages(zero_page, compound_order(zero_page));
goto retry;
}
@@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct shrinker *shrink,
if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) {
struct page *zero_page = xchg(&huge_zero_page, NULL);
BUG_ON(zero_page == NULL);
- __free_page(zero_page);
+ __free_pages(zero_page, compound_order(zero_page));
return HPAGE_PMD_NR;
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v2 2/2] mm: verify compound order when freeing a page
2014-10-15 19:20 [PATCH v2 1/2] mm: free compound page with correct order Yu Zhao
@ 2014-10-15 19:20 ` Yu Zhao
2014-10-15 20:07 ` Kirill A. Shutemov
2014-10-15 19:30 ` [PATCH v2 1/2] mm: free compound page with correct order Andrew Morton
1 sibling, 1 reply; 6+ messages in thread
From: Yu Zhao @ 2014-10-15 19:20 UTC (permalink / raw)
To: Andrew Morton, Kirill A. Shutemov, Mel Gorman, Rik van Riel,
Ingo Molnar, Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka
Cc: linux-mm, linux-kernel, stable, Yu Zhao
This allows us to catch the bug fixed in the previous patch
(mm: free compound page with correct order).
Here we also verify whether a page is tail page or not -- tail
pages are supposed to be freed along with their head, not by
themselves.
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Yu Zhao <yuzhao@google.com>
---
mm/page_alloc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 736d8e1..5bf44e4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -750,6 +750,9 @@ static bool free_pages_prepare(struct page *page, unsigned int order)
int i;
int bad = 0;
+ VM_BUG_ON_PAGE(PageTail(page), page);
+ VM_BUG_ON_PAGE(PageHead(page) && compound_order(page) != order, page);
+
trace_mm_page_free(page, order);
kmemcheck_free_shadow(page, order);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] mm: free compound page with correct order
2014-10-15 19:20 [PATCH v2 1/2] mm: free compound page with correct order Yu Zhao
2014-10-15 19:20 ` [PATCH v2 2/2] mm: verify compound order when freeing a page Yu Zhao
@ 2014-10-15 19:30 ` Andrew Morton
2014-10-15 20:05 ` Kirill A. Shutemov
2014-10-24 20:13 ` Yu Zhao
1 sibling, 2 replies; 6+ messages in thread
From: Andrew Morton @ 2014-10-15 19:30 UTC (permalink / raw)
To: Yu Zhao
Cc: Kirill A. Shutemov, Mel Gorman, Rik van Riel, Ingo Molnar,
Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka, linux-mm, linux-kernel, stable
On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao <yuzhao@google.com> wrote:
> Compound page should be freed by put_page() or free_pages() with
> correct order. Not doing so will cause tail pages leaked.
>
> The compound order can be obtained by compound_order() or use
> HPAGE_PMD_ORDER in our case. Some people would argue the latter
> is faster but I prefer the former which is more general.
>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
> Cc: stable@vger.kernel.org (v3.8+)
It's two years old and nobody noticed the memory leak, so presumably it
happens rarely.
> Signed-off-by: Yu Zhao <yuzhao@google.com>
> ---
> mm/huge_memory.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 74c78aa..780d12c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -200,7 +200,7 @@ retry:
> preempt_disable();
> if (cmpxchg(&huge_zero_page, NULL, zero_page)) {
> preempt_enable();
> - __free_page(zero_page);
> + __free_pages(zero_page, compound_order(zero_page));
This is rare.
> goto retry;
> }
>
> @@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct shrinker *shrink,
> if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) {
> struct page *zero_page = xchg(&huge_zero_page, NULL);
> BUG_ON(zero_page == NULL);
> - __free_page(zero_page);
> + __free_pages(zero_page, compound_order(zero_page));
But I'm surprised that this is also rare. It makes me wonder if this
code is working correctly.
> return HPAGE_PMD_NR;
> }
Were you able to observe the leakage in practice? If so, under what
circumstances?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] mm: free compound page with correct order
2014-10-15 19:30 ` [PATCH v2 1/2] mm: free compound page with correct order Andrew Morton
@ 2014-10-15 20:05 ` Kirill A. Shutemov
2014-10-24 20:13 ` Yu Zhao
1 sibling, 0 replies; 6+ messages in thread
From: Kirill A. Shutemov @ 2014-10-15 20:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Yu Zhao, Kirill A. Shutemov, Mel Gorman, Rik van Riel,
Ingo Molnar, Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka, linux-mm, linux-kernel, stable
On Wed, Oct 15, 2014 at 12:30:44PM -0700, Andrew Morton wrote:
> > @@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct shrinker *shrink,
> > if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) {
> > struct page *zero_page = xchg(&huge_zero_page, NULL);
> > BUG_ON(zero_page == NULL);
> > - __free_page(zero_page);
> > + __free_pages(zero_page, compound_order(zero_page));
>
> But I'm surprised that this is also rare. It makes me wonder if this
> code is working correctly.
This should be rare too. To get here we need a situation when huge zero
page is allocated, but not mapped and we get memory presure to trigger
shrinker.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 2/2] mm: verify compound order when freeing a page
2014-10-15 19:20 ` [PATCH v2 2/2] mm: verify compound order when freeing a page Yu Zhao
@ 2014-10-15 20:07 ` Kirill A. Shutemov
0 siblings, 0 replies; 6+ messages in thread
From: Kirill A. Shutemov @ 2014-10-15 20:07 UTC (permalink / raw)
To: Yu Zhao
Cc: Andrew Morton, Kirill A. Shutemov, Mel Gorman, Rik van Riel,
Ingo Molnar, Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka, linux-mm, linux-kernel, stable
On Wed, Oct 15, 2014 at 12:20:05PM -0700, Yu Zhao wrote:
> This allows us to catch the bug fixed in the previous patch
> (mm: free compound page with correct order).
>
> Here we also verify whether a page is tail page or not -- tail
> pages are supposed to be freed along with their head, not by
> themselves.
>
> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
I didn't give this tag. It's okay in this case, but please do not assume
that you've got Reviewed-by, unless the person said it explicitly.
> Signed-off-by: Yu Zhao <yuzhao@google.com>
Your Singed-off-by should come first.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2 1/2] mm: free compound page with correct order
2014-10-15 19:30 ` [PATCH v2 1/2] mm: free compound page with correct order Andrew Morton
2014-10-15 20:05 ` Kirill A. Shutemov
@ 2014-10-24 20:13 ` Yu Zhao
1 sibling, 0 replies; 6+ messages in thread
From: Yu Zhao @ 2014-10-24 20:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Kirill A. Shutemov, Mel Gorman, Rik van Riel, Ingo Molnar,
Hugh Dickins, Sasha Levin, Bob Liu, Johannes Weiner,
David Rientjes, Vlastimil Babka, linux-mm, linux-kernel, stable
On Wed, Oct 15, 2014 at 12:30:44PM -0700, Andrew Morton wrote:
> On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao <yuzhao@google.com> wrote:
>
> > Compound page should be freed by put_page() or free_pages() with
> > correct order. Not doing so will cause tail pages leaked.
> >
> > The compound order can be obtained by compound_order() or use
> > HPAGE_PMD_ORDER in our case. Some people would argue the latter
> > is faster but I prefer the former which is more general.
> >
> > Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
> > Cc: stable@vger.kernel.org (v3.8+)
>
> It's two years old and nobody noticed the memory leak, so presumably it
> happens rarely.
>
> > Signed-off-by: Yu Zhao <yuzhao@google.com>
> > ---
> > mm/huge_memory.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 74c78aa..780d12c 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -200,7 +200,7 @@ retry:
> > preempt_disable();
> > if (cmpxchg(&huge_zero_page, NULL, zero_page)) {
> > preempt_enable();
> > - __free_page(zero_page);
> > + __free_pages(zero_page, compound_order(zero_page));
>
> This is rare.
>
> > goto retry;
> > }
> >
> > @@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct shrinker *shrink,
> > if (atomic_cmpxchg(&huge_zero_refcount, 1, 0) == 1) {
> > struct page *zero_page = xchg(&huge_zero_page, NULL);
> > BUG_ON(zero_page == NULL);
> > - __free_page(zero_page);
> > + __free_pages(zero_page, compound_order(zero_page));
>
> But I'm surprised that this is also rare. It makes me wonder if this
> code is working correctly.
>
> > return HPAGE_PMD_NR;
> > }
>
> Were you able to observe the leakage in practice? If so, under what
> circumstances?
Yes, not just on our servers (the worst case we saw is 11G leaked on
a 48G machine) but also on our workstations running Ubuntu based distro.
$ cat /proc/vmstat | grep thp_zero_page_alloc
thp_zero_page_alloc 55
thp_zero_page_alloc_failed 0
This means there is (thp_zero_page_alloc - 1) * (2M - 4K) memory leaked.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-24 20:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-15 19:20 [PATCH v2 1/2] mm: free compound page with correct order Yu Zhao
2014-10-15 19:20 ` [PATCH v2 2/2] mm: verify compound order when freeing a page Yu Zhao
2014-10-15 20:07 ` Kirill A. Shutemov
2014-10-15 19:30 ` [PATCH v2 1/2] mm: free compound page with correct order Andrew Morton
2014-10-15 20:05 ` Kirill A. Shutemov
2014-10-24 20:13 ` Yu Zhao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).