On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao <yuzhao@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
> Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
> Cc: stable@xxxxxxxxxxxxxxx (v3.8+)
It's two years old and nobody noticed the memory leak, so presumably it
happens rarely.
> Signed-off-by: Yu Zhao <yuzhao@xxxxxxxxxx>
> ---
> 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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html