From: Hugh Dickins <hugh@veritas.com>

mremap's move_vma should think ahead to lessen the chance of failure during
its rewind on failure: running out of memory always possible, but it's silly
for it to embark when it's near the map_count limit.


---

 25-akpm/mm/mremap.c |    7 +++++++
 1 files changed, 7 insertions(+)

diff -puN mm/mremap.c~mremap-check-map_count mm/mremap.c
--- 25/mm/mremap.c~mremap-check-map_count	2004-04-03 03:00:18.578407208 -0800
+++ 25-akpm/mm/mremap.c	2004-04-03 03:00:18.581406752 -0800
@@ -176,6 +176,13 @@ static unsigned long move_vma(struct vm_
 	unsigned long excess = 0;
 	int split = 0;
 
+	/*
+	 * We'd prefer to avoid failure later on in do_munmap:
+	 * which may split one vma into three before unmapping.
+	 */
+	if (mm->map_count >= sysctl_max_map_count - 3)
+		return -ENOMEM;
+
 	new_pgoff = vma->vm_pgoff + ((old_addr - vma->vm_start) >> PAGE_SHIFT);
 	new_vma = copy_vma(vma, new_addr, new_len, new_pgoff);
 	if (!new_vma)

_