|MALLOC(9)||Kernel Developer's Manual||MALLOC(9)|
size, int type,
nmemb, size_t size,
*addr, int type,
malloc() function allocates uninitialized memory in kernel address space for an object whose size is specified by size.
mallocarray() function is the same as
malloc(), but allocates space for an array of
nmemb objects and checks for arithmetic overflow.
free() function releases memory at
address addr that was previously allocated by
for re-use. The same object size originally provided to
malloc() should be specified by
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
mallocarray() as follows:
malloc() may call sleep to wait for resources to be released by other processes.
malloc() to return
NULLif the request cannot be immediately fulfilled due to resource shortage.
M_WAITOKcase, if not enough memory is available, return
NULLinstead of calling panic(9). If
mallocarray() detects an overflow or
malloc() detects an excessive allocation, return
NULLinstead of calling panic(9).
M_WAITOK must be specified via the
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
The following types are currently defined:
mallocarray() can be called during autoconf, from process context, or from interrupt context if
M_NOWAITis passed via flags. They can't be called from interrupt context if
M_WAITOKis passed via flags.
free() can be called during autoconf, from
process context, or from interrupt context.
mallocarray() return a kernel virtual address that is suitably aligned for storage of any type of object.
DIAGNOSTICconfiguration option attempts to detect memory corruption caused by such things as writing outside the allocated area and unbalanced calls to
free(). Failing consistency checks will cause a panic or a system console message:
MALLOC_DEBUGoption 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_DEBUGcan also be specified as an allocation type to force allocation with debugging.
Every call to
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
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.
|November 14, 2016||OpenBSD-6.2|