On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao <[email protected]> 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 <[email protected]> > Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page") > Cc: [email protected] (v3.8+) It's two years old and nobody noticed the memory leak, so presumably it happens rarely. > Signed-off-by: Yu Zhao <[email protected]> > --- > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
