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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>