linux-kernel - Re: [PATCH v2 1/2] mm: free compound page with correct order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20141024201346.GA27746@google.com>
Date:	Fri, 24 Oct 2014 13:13:46 -0700
From:	Yu Zhao <yuzhao@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Hugh Dickins <hughd@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Bob Liu <lliubbo@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	David Rientjes <rientjes@...gle.com>,
	Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] mm: free compound page with correct order

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@...gle.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@...ux.intel.com>
> > Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
> > Cc: stable@...r.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@...gle.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/