MALLOC(9) | Kernel Developer's Manual | MALLOC(9) |
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
malloc
() may
call sleep to wait for resources to be released by other processes.M_NOWAIT
malloc
() to return
NULL
if the request cannot be immediately
fulfilled due to resource shortage.M_CANFAIL
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
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:
M_FREE
M_DEVBUF
M_DEBUG
malloc
debug structures.M_PCB
M_RTABLE
M_FTABLE
M_IFADDR
M_SOOPTS
M_SYSCTL
M_COUNTERS
M_IOCTLOPS
M_IOV
M_MOUNT
M_NFSREQ
M_NFSMNT
M_VNODE
M_CACHE
M_DQUOT
M_UFSMNT
M_SHM
M_VMMAP
M_SEM
M_DIRHASH
M_ACPI
M_VMPMAP
M_FILE
M_FILEDESC
M_PROC
M_SUBPROC
M_VCLUSTER
M_MFSNODE
M_NETADDR
M_NFSSVC
M_NFSD
M_IPMOPTS
M_IPMADDR
M_IFMADDR
M_MRTABLE
M_ISOFSMNT
M_ISOFSNODE
M_MSDOSFSMNT
M_MSDOSFSFAT
M_MSDOSFSNODE
M_TTYS
M_EXEC
M_MISCFSMNT
M_FUSEFS
M_PFKEY
M_TDB
M_XDATA
M_PAGEDEP
M_INODEDEP
M_NEWBLK
M_INDIRDEP
M_VMSWAP
M_UVMAMAP
M_UVMAOBJ
M_USB
M_USBDEV
M_USBHC
M_MEMDESC
M_CRYPTO_DATA
M_CREDENTIALS
M_EMULDATA
M_IP6OPT
M_IP6NDP
M_TEMP
M_NTFSMNT
M_NTFSNTNODE
M_NTFSNODE
M_NTFSDIR
M_NTFSHASH
M_NTFSVATTR
M_NTFSRDATA
M_NTFSDECOMP
M_NTFSRUN
M_KEVENT
M_UDFMOUNT
M_UDFFENTRY
M_UDFFID
M_AGP
M_DRM
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:
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.
November 14, 2016 | OpenBSD-6.1 |