malloc,
mallocarray,
free —
kernel
memory allocator
#include
<sys/types.h>
#include
<sys/malloc.h>
void *
malloc(
size_t
size,
int
type,
int
flags);
void *
mallocarray(
size_t
nmemb,
size_t
size,
int
type,
int
flags);
void
free(
void
*addr,
int
type,
size_t
size);
The
malloc() function allocates uninitialized
memory in kernel address space for an object whose size is specified by
size.
The
mallocarray() function is the same as
malloc(), but allocates space for an array of
nmemb objects and checks for arithmetic
overflow.
The
free() function releases memory at address
addr that was previously allocated by
malloc() or
mallocarray() for re-use. The same object size
originally provided to
malloc() should be
specified by
size, because
free() will operate faster knowing this. If
tracking the size is difficult, specify
size
as 0. If
addr is a null pointer, no action
occurs.
The
flags argument affects the operational
characteristics of
malloc() and
mallocarray() as follows:
-
-
M_WAITOK- If memory is currently unavailable,
malloc() may call sleep to wait for resources
to be released by other processes.
-
-
M_NOWAIT- Causes malloc() to return
NULL if the request cannot be
immediately fulfilled due to resource shortage.
-
-
M_CANFAIL- In the
M_WAITOK case, if
not enough memory is available, return
NULL instead of calling
panic(9). If
mallocarray() detects an overflow or
malloc() detects an excessive allocation,
return NULL instead of calling
panic(9).
-
-
M_ZERO- Causes allocated memory to be zeroed.
One of
M_NOWAIT or
M_WAITOK must be specified via the
flags argument.
The
type argument broadly identifies the kernel
subsystem for which the allocated memory was needed, and is commonly used to
maintain statistics about kernel memory usage. These statistics can be
examined using
vmstat(8) or
systat(1) if either of the
kernel
options(4)
KMEMSTATS or
DEBUG
are enabled.
The following types are currently defined:
malloc() and
mallocarray() can be called during autoconf, from
process context, or from interrupt context if
M_NOWAIT is passed via
flags. They can't be called from interrupt
context if
M_WAITOK is passed via
flags.
free() can be called during autoconf, from process
context, or from interrupt context.
malloc() and
mallocarray() return a kernel virtual address
that is suitably aligned for storage of any type of object.
A kernel compiled with the
DIAGNOSTIC
configuration option attempts to detect memory corruption caused by such
things as writing outside the allocated area and unbalanced calls to
malloc() or
mallocarray(), and
free(). Failing consistency checks will cause a
panic or a system console message:
- panic: “malloc: bogus
type”
- panic: “malloc: out of
space in kmem_map”
- panic: “malloc:
allocation too large”
- panic: “malloc: wrong
bucket”
- panic: “malloc: lost
data”
- panic: “mallocarray:
overflow”
- panic: “free:
unaligned addr”
- panic: “free:
duplicated free”
- panic: “free: multiple
frees”
- panic: “free:
non-malloced addr”
- panic: “free: size too
large”
- panic: “free: size too
small”
- panic: “kmeminit:
minbucket too small/struct freelist too big”
- “multiply freed item
⟨addr⟩”
- “Data modified on
freelist: ⟨data object description⟩”
A kernel compiled with the
MALLOC_DEBUG option
allows for more extensive debugging of memory allocations. The
debug_malloc_type,
debug_malloc_size,
debug_malloc_size_lo and
debug_malloc_size_hi variables choose which
allocation to debug.
debug_malloc_type should
be set to the memory type and
debug_malloc_size should be set to the memory
size to debug. 0 can be used as a wildcard.
debug_malloc_size_lo and
debug_malloc_size_hi can be used to specify a
range of sizes if the exact size to debug is not known. When those are used,
debug_malloc_size needs to be set to the
wildcard.
M_DEBUG can also be specified as
an allocation type to force allocation with debugging.
Every call to
malloc() or
mallocarray() with a memory type and size that
matches the debugged type and size will allocate two virtual pages. The
pointer returned will be aligned so that the requested area will end at the
page boundary and the second virtual page will be left unmapped. This way we
can catch reads and writes outside the allocated area.
Every call to
free() with memory that was returned
by the debugging allocators will cause the memory area to become unmapped so
that we can catch dangling reads and writes to freed memory.
There are no special diagnostics if any errors are caught by the debugging
malloc. The errors will look like normal access to unmapped memory. On a
memory access error, the
show malloc command in
ddb(4) can be invoked to see what
memory areas are allocated and freed. If the faulting address is within two
pages from an address on the allocated list, there was an access outside the
allocated area. If the faulting address is within two pages from an address on
the free list, there was an access to freed memory.
Care needs to be taken when using the
MALLOC_DEBUG
option: the memory consumption can run away pretty quickly and there is a
severe performance degradation when allocating and freeing debugged memory
types.
systat(1),
vmstat(8)
![[OpenBSD]](/openbsd.gif){kind=small}