Re: Huge pages: Memory leak on mmap failure

[Dave Hansen <dave@linux.vnet.ibm.com>]

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>