site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, 8-). - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On May 9, 2008, at 11:12 AM, Stacey wrote: 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(). 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". This email sent to site_archiver@lists.apple.com