Re: When will kalloc() return NULL?
Re: When will kalloc() return NULL?
- Subject: Re: When will kalloc() return NULL?
- From: Terry Lambert <email@hidden>
- Date: Fri, 9 May 2008 20:48:10 -0700
On May 9, 2008, at 11:12 AM, Stacey wrote:
Hi,
Given kalloc(size) where 0 < size < kalloc_max_pre_rounded (small
enough to be handled by zalloc)...
When it is safe to assume that kalloc(size) (aka.
kalloc_canblock(size, TRUE)) will never return NULL or, in other
words, block until memory resources are available? I see examples
in the Xnu code that make both assumptions.
If it is never safe to assume kalloc(size) will never return NULL is
there a kernel memory allocator call that will block until memory is
available.
Sorry if this question has been asked before.
Whenever kmem_alloc() returns something other than KERN_SUCCESS or
zalloc_canblock() returns NULL to kalloc_canblock().
8-).
zalloc_canblock() can return NULL if addr is 0 and it's an exhaustible
zone, and the zone can't be grown.
kmem_alloc() can fail with KERN_INVALID_ARGUMENT or anything that
vm_map_find_space() can return, and it can return
KERN_RESOURCE_SHORTAGE. vm_map_find_space() will return
KERN_INVALID_ARGUMENT or KERN_NO_SPACE in some cases.
So basically, if you ask for 8K or less, and the zone is exhaustible,
or if you ask for more than 8K and there isn't sufficient contiguous
kernel virtual memory to satisfy the request, it can return NULL.
If it's coming from one of the power of two zones, then if you run out
of KVA before you run out the zone of zones to create mappings for
what you want to allocate, then it will fail to get allocations of 8K
or less, and if you ask for more than 8K and something has eaten all
your avaialbe virtual address space, it can fail.
If you ask for 8K or less, and the zone of zones is exhausted, since
it can't be grown at interrupt level, then you'll get a
zalloc_canblock panic, usually with a return code of 3 (KERN_NO_SPACE).
There's been debate over whether or not to return NULL in this case
instead of panic'ing, but as you noted, not all kernel code is safe
under resource exhaustion conditions, since it doesn't check the
allocation return to see that the allocation was in fact successful
before dereferencing the pointer or passing it off to someone else for
them to dereference and panic.
The debate centers around the philosophy of what you should do under
resource starvation situations. In general, there are two approaches:
(1) block until the heat death of the universe, waiting for your
allocation which is never going to be satisfied to be satisfied
(2) return NULL and make all your code capable of unwinding it's
partially accumulated state up to that point, in the faint hope that
by doing this, something else will make forward progress and free up
enough resources that when you retry, it will be successful
Since the code came from diverse source bases, some code takes one
philosophy, while other code takes the other.
-
In general, we set our administrative limits low enough that no one
bumps their head on dereferencing a NULL pointer or a
zalloc_canblock() panic, unless they have a bug in their code (e.g.
leaking IPC ports, leaking buffers, asking for unreasonable amounts of
kernel virtual memory late in the system lifetime after the KVA has
been fragmented, etc.).
So our philosophy can be currently called "don't let people get to the
point of resource exhaustion in the first place so no one has to ask
the question about what we do when we hit resource exhaustion".
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden