Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

NetBSD 6.1.5 - man page for kmem_zalloc (netbsd section 9)

KMEM(9) 			  BSD Kernel Developer's Manual 			  KMEM(9)

     kmem -- kernel wired memory allocator

     #include <sys/kmem.h>

     void *
     kmem_alloc(size_t size, km_flag_t kmflags);

     void *
     kmem_zalloc(size_t size, km_flag_t kmflags);

     kmem_free(void *p, size_t size);

     char *
     kmem_asprintf(const char *fmt, ...);

     options DEBUG

     kmem_alloc() allocates kernel wired memory.  It takes the following arguments.

     size     Specify the size of allocation in bytes.

     kmflags  Either of the following:

	      KM_SLEEP	  If the allocation cannot be satisfied immediately, sleep until enough
			  memory is available.

	      KM_NOSLEEP  Don't sleep.	Immediately return NULL if there is not enough memory
			  available.  It should only be used when failure to allocate will not
			  have harmful, user-visible effects.

			  Use of KM_NOSLEEP is strongly discouraged as it can create transient,
			  hard to debug failures that occur when the system is under memory pres-

			  In situations where it is not possible to sleep, for example because
			  locks are held by the caller, the code path should be restructured to
			  allow the allocation to be made in another place.

     The contents of allocated memory are uninitialized.

     Unlike Solaris, kmem_alloc(0, flags) is illegal.

     kmem_zalloc() is the equivalent of kmem_alloc(), except that it initializes the memory to

     kmem_asprintf() functions as the well known asprintf() function, but allocates memory using
     kmem_alloc().  This routine can sleep during allocation.  The size of the allocated area is
     the length of the returned character string, plus one (for the NUL terminator).  This must
     be taken into consideration when freeing the returned area with kmem_free().

     kmem_free() frees kernel wired memory allocated by kmem_alloc() or kmem_zalloc() so that it
     can be used for other purposes.  It takes the following arguments.

     p	      The pointer to the memory being freed.  It must be the one returned by kmem_alloc()
	      or kmem_zalloc().

     size     The size of the memory being freed, in bytes.  It must be the same as the size
	      argument used for kmem_alloc() or kmem_zalloc() when the memory was allocated.

     Freeing NULL is illegal.

     Making KM_SLEEP allocations while holding mutexes or reader/writer locks is discouraged, as
     the caller can sleep for an unbounded amount of time in order to satisfy the allocation.
     This can in turn block other threads that wish to acquire locks held by the caller.  It
     should be noted that kmem_free() may also block.

     For some locks this is permissible or even unavoidable.  For others, particularly locks that
     may be taken from soft interrupt context, it is a serious problem.  As a general rule it is
     better not to allow this type of situation to develop.  One way to circumvent the problem is
     to make allocations speculative and part of a retryable sequence.	For example:

	     /* speculative unlocked check */
	     if (need to allocate) {
		     new_item = kmem_alloc(sizeof(*new_item), KM_SLEEP);
	     } else {
		     new_item = NULL;
	     /* check while holding lock for true status */
	     if (need to allocate) {
		     if (new_item == NULL) {
			     goto retry;
		     new_item = NULL;
	     if (new_item != NULL) {
		     /* did not use it after all */
		     kmem_free(new_item, sizeof(*new_item));

     Kernels compiled with the DEBUG option perform CPU intensive sanity checks on kmem opera-
     tions, and include the kmguard facility which can be enabled at runtime.

     kmguard adds additional, very high overhead runtime verification to kmem operations.  To
     enable it, boot the system with the -d option, which causes the debugger to be entered early
     during the kernel boot process.  Issue commands such as the following:

     db> w kmem_guard_depth 0t30000
     db> c

     This instructs kmguard to queue up to 60000 (30000*2) pages of unmapped KVA to catch use-
     after-free type errors.  When kmem_free() is called, memory backing a freed item is unmapped
     and the kernel VA space pushed onto a FIFO.  The VA space will not be reused until another
     30k items have been freed.  Until reused the kernel will catch invalid accesses and panic
     with a page fault.  Limitations:

     o	 It has a severe impact on performance.

     o	 It is best used on a 64-bit machine with lots of RAM.

     o	 Allocations larger than PAGE_SIZE bypass the kmguard facility.

     kmguard tries to catch the following types of bugs:

     o	 Overflow at time of occurrence, by means of a guard page.

     o	 Underflow at kmem_free(), by using a canary value.

     o	 Invalid pointer or size passed, at kmem_free().

     On success, kmem_alloc() and kmem_zalloc() return a pointer to allocated memory.  Otherwise,
     NULL is returned.

     The kmem subsystem is implemented within the file sys/kern/subr_kmem.c.

     intro(9), memoryallocators(9), percpu(9), pool_cache(9), uvm_km(9)

     Neither kmem_alloc() nor kmem_free() can be used from interrupt context, from a soft inter-
     rupt, or from a callout.  Use pool_cache(9) in these situations.

     As the memory allocated by kmem_alloc() is uninitialized, it can contain security-sensitive
     data left by its previous user.  It is the caller's responsibility not to expose it to the

BSD					  June 14, 2011 				      BSD

All times are GMT -4. The time now is 05:00 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password