summaryrefslogtreecommitdiffstats
path: root/mm/vmscan.c
diff options
context:
space:
mode:
authorDave Hansen2012-05-30 00:06:46 +0200
committerLinus Torvalds2012-05-30 01:22:24 +0200
commitc50ac050811d6485616a193eb0f37bfbd191cc89 (patch)
treee237c67e83182bad5744e17c867bb6bceb207544 /mm/vmscan.c
parentmm/bootmem.c: cleanup on addition to bootmem data list (diff)
downloadkernel-qcow2-linux-c50ac050811d6485616a193eb0f37bfbd191cc89.tar.gz
kernel-qcow2-linux-c50ac050811d6485616a193eb0f37bfbd191cc89.tar.xz
kernel-qcow2-linux-c50ac050811d6485616a193eb0f37bfbd191cc89.zip
hugetlb: fix resv_map leak in error path
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(). This is a decent fix. This leak could get reintroduced if new code (say, after hugetlb_reserve_pages() in hugetlbfs_file_mmap()) decides to return an error. But, I think it would have to unroll the reservation anyway. Christoph's test case: http://marc.info/?l=linux-mm&m=133728900729735 This patch applies to 3.4 and later. A version for earlier kernels is at https://lkml.org/lkml/2012/5/22/418. Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com> Acked-by: Mel Gorman <mel@csn.ul.ie> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reported-by: Christoph Lameter <cl@linux.com> Tested-by: Christoph Lameter <cl@linux.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: <stable@vger.kernel.org> [2.6.32+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/vmscan.c')
0 files changed, 0 insertions, 0 deletions