From f38512f4af387af6e11bc0b5508d0832fe10d7e3 Mon Sep 17 00:00:00 2001
From: Jason Evans <jasone@FreeBSD.org>
Date: Thu, 3 Jan 2008 23:22:13 +0000
Subject: [PATCH] Enable both sbrk(2)- and mmap(2)-based memory acquisition
 methods by default.  This has the disadvantage of rendering the datasize
 resource limit irrelevant, but without this change, legitimate uses of more
 memory than will fit in the data segment are thwarted by default.

Fix chunk_alloc_mmap() to work correctly if initial mapping is not
chunk-aligned and mapping extension fails.
---
 lib/libc/stdlib/malloc.3 | 24 ++++++++++++------------
 lib/libc/stdlib/malloc.c | 15 ++++++++-------
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/lib/libc/stdlib/malloc.3 b/lib/libc/stdlib/malloc.3
index 7138ead52e7..466accc1b32 100644
--- a/lib/libc/stdlib/malloc.3
+++ b/lib/libc/stdlib/malloc.3
@@ -32,7 +32,7 @@
 .\"     @(#)malloc.3	8.1 (Berkeley) 6/4/93
 .\" $FreeBSD$
 .\"
-.Dd December 27, 2007
+.Dd January 3, 2008
 .Dt MALLOC 3
 .Os
 .Sh NAME
@@ -245,7 +245,7 @@ This option is not available for some configurations (non-PIC).
 Use
 .Xr mmap 2
 to acquire anonymously mapped memory.
-This option is disabled by default.
+This option is enabled by default.
 If both the
 .Dq D
 and
@@ -335,24 +335,24 @@ Traditionally, allocators have used
 to obtain memory, which is suboptimal for several reasons, including race
 conditions, increased fragmentation, and artificial limitations on maximum
 usable memory.
-This allocator uses
+This allocator uses both
 .Xr sbrk 2
-by default in order to facilitate resource limits, but it can be configured at
-run time to use
-.Xr sbrk 2
-and/or
-.Xr mmap 2 .
+and
+.Xr mmap 2
+by default, but it can be configured at run time to use only one or the other.
 If resource limits are not a primary concern, the preferred configuration is
 .Ev MALLOC_OPTIONS=dM
 or
 .Ev MALLOC_OPTIONS=DM .
 When so configured, the
 .Ar datasize
-resource limit has little practical effect for typical applications.
-The
+resource limit has little practical effect for typical applications; use
+.Ev MALLOC_OPTIONS=Dm
+if that is a concern.
+Regardless of allocator configuration, the
 .Ar vmemoryuse
-resource limit, however, can be used to bound the total virtual memory used by
-a process, as described in
+resource limit can be used to bound the total virtual memory used by a
+process, as described in
 .Xr limits 1 .
 .Pp
 This allocator uses multiple arenas in order to reduce lock contention for
diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c
index 5c987c54af0..abe367a811f 100644
--- a/lib/libc/stdlib/malloc.c
+++ b/lib/libc/stdlib/malloc.c
@@ -1,5 +1,5 @@
 /*-
- * Copyright (C) 2006,2007 Jason Evans <jasone@FreeBSD.org>.
+ * Copyright (C) 2006-2008 Jason Evans <jasone@FreeBSD.org>.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -131,7 +131,7 @@
  * unnecessary, but we are burdened by history and the lack of resource limits
  * for anonymous mapped memory.
  */
-#define MALLOC_DSS
+#define	MALLOC_DSS
 
 #include <sys/cdefs.h>
 __FBSDID("$FreeBSD$");
@@ -821,7 +821,7 @@ static bool	opt_junk = false;
 #endif
 #ifdef MALLOC_DSS
 static bool	opt_dss = true;
-static bool	opt_mmap = false;
+static bool	opt_mmap = true;
 #endif
 static bool	opt_hint = false;
 #ifdef MALLOC_LAZY_FREE
@@ -1646,6 +1646,7 @@ chunk_alloc_mmap(size_t size)
 				return (NULL);
 
 			/* Clean up unneeded leading/trailing space. */
+			offset = CHUNK_ADDR2OFFSET(ret);
 			if (offset != 0) {
 				/* Leading space. */
 				pages_unmap(ret, chunksize - offset);
@@ -1661,11 +1662,11 @@ chunk_alloc_mmap(size_t size)
 				pages_unmap((void *)((uintptr_t)ret + size),
 				    chunksize);
 			}
+		} else {
+			/* Clean up unneeded leading space. */
+			pages_unmap(ret, chunksize - offset);
+			ret = (void *)((uintptr_t)ret + (chunksize - offset));
 		}
-
-		/* Clean up unneeded leading space. */
-		pages_unmap(ret, chunksize - offset);
-		ret = (void *)((uintptr_t)ret + (chunksize - offset));
 	}
 
 	return (ret);