Huge pages: Memory leak on mmap failure

Huge pages: Memory leak on mmap failure

[Christoph Lameter]

On 2.6.32 and 3.4-rc6 mmap failure of a huge page causes a memory
leak. The 32 byte kmalloc cache grows by 10 mio entries if running
the following code:

--------
#include <sys/mman.h>
#include <stdlib.h>

#ifndef MAP_HUGETLB
#define MAP_HUGETLB 0x0040000
#endif

int main() {
    for (int i=0; i!=10000000; ++i) {
        void* ptr=mmap(NULL, 2*1024*1024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, 0, 0);
        if (ptr!=MAP_FAILED) abort();
    }
    return 0;
}

-------


g++ -O2 test.cpp && echo good
good

$ egrep 'SUnreclaim|HugePages_Total' /proc/meminfo
SUnreclaim:      1900756 kB
HugePages_Total:       0

$ ./a.out && echo good
good

$ egrep 'SUnreclaim|HugePages_Total' /proc/meminfo
SUnreclaim:      2213268 kB
HugePages_Total:       0

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Huge pages: Memory leak on mmap failure

[Dave Hansen]

On 05/17/2012 02:07 PM, Christoph Lameter wrote:
> 
> On 2.6.32 and 3.4-rc6 mmap failure of a huge page causes a memory
> leak. The 32 byte kmalloc cache grows by 10 mio entries if running
> the following code:

Urg.  Looks like the resv_maps, probably.  I'll take a look.


--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Huge pages: Memory leak on mmap failure

[Dave Hansen]

On 05/17/2012 02:07 PM, Christoph Lameter wrote:
> 
> On 2.6.32 and 3.4-rc6 mmap failure of a huge page causes a memory
> leak. The 32 byte kmalloc cache grows by 10 mio entries if running
> the following code:

When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
does a resv_map_alloc().  It depends on code in hugetlbfs's
vm_ops->close() to release that allocation.

However, in the mmap() failure path, we do a plain unmap_region()
without the remove_vma() which actually calls vm_ops->close().

As the code stands today, I think we can fix this by just making sure we
release the resv_map after hugetlb_acct_memory() fails.  But, this seems
like a bit of a superficial fix and if we end up with another path or
two that can return -ESOMETHING, this might get reintroduced.  The
assumption that vm_ops->close() will get called on all VMAs passed in to
hugetlbfs_file_mmap() seems like something that needs to get corrected.

I'll take a look, but I'm really curious what Mel thinks.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Huge pages: Memory leak on mmap failure

[KOSAKI Motohiro]

On Thu, May 17, 2012 at 6:50 PM, Dave Hansen <dave@linux.vnet.ibm.com> wrote:
> On 05/17/2012 02:07 PM, Christoph Lameter wrote:
>>
>> On 2.6.32 and 3.4-rc6 mmap failure of a huge page causes a memory
>> leak. The 32 byte kmalloc cache grows by 10 mio entries if running
>> the following code:
>
> When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
> does a resv_map_alloc().  It depends on code in hugetlbfs's
> vm_ops->close() to release that allocation.
>
> However, in the mmap() failure path, we do a plain unmap_region()
> without the remove_vma() which actually calls vm_ops->close().
>
> As the code stands today, I think we can fix this by just making sure we
> release the resv_map after hugetlb_acct_memory() fails.  But, this seems
> like a bit of a superficial fix and if we end up with another path or
> two that can return -ESOMETHING, this might get reintroduced.  The
> assumption that vm_ops->close() will get called on all VMAs passed in to
> hugetlbfs_file_mmap() seems like something that needs to get corrected.

I agree. Now, resv_map_alloc() is called file open path and
resv_map_free() is called vma close path. It seems asymmetry.
It would be nice if resv_map_alloc can use vma->open ops.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Huge pages: Memory leak on mmap failure

[Mel Gorman]

On Thu, May 17, 2012 at 03:50:17PM -0700, Dave Hansen wrote:
> On 05/17/2012 02:07 PM, Christoph Lameter wrote:
> > 
> > On 2.6.32 and 3.4-rc6 mmap failure of a huge page causes a memory
> > leak. The 32 byte kmalloc cache grows by 10 mio entries if running
> > the following code:
> 
> When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
> does a resv_map_alloc().  It depends on code in hugetlbfs's
> vm_ops->close() to release that allocation.
> 
> However, in the mmap() failure path, we do a plain unmap_region()
> without the remove_vma() which actually calls vm_ops->close().
> 
> As the code stands today, I think we can fix this by just making sure we
> release the resv_map after hugetlb_acct_memory() fails. 

This appears to be the most practical solution.

> But, this seems
> like a bit of a superficial fix and if we end up with another path or
> two that can return -ESOMETHING, this might get reintroduced.  The
> assumption that vm_ops->close() will get called on all VMAs passed in to
> hugetlbfs_file_mmap() seems like something that needs to get corrected.
> 

It does not look practical to move the allocation to somewhere like
hugetlb_vm_op_open() as minimally that operation is never expected to
fail. That leaves no sane way to communicate that a kmalloc() failed
for example.  ->close() will get called once hugetlb_reserve_pages()
returns successfully so right now, I'm not seeing a better fix than the
superficial fix.

-- 
Mel Gorman
SUSE Labs

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>