On Dec 11, 7:25am, [email protected] (Brian Buhrow) wrote: -- Subject: Re: kernel memory allocation failures
| Hello. I'm coming to this rather late, but my understanding is that | if you use malloc() in the kernel, you need to check to make sure you have | actually gotten that memory on return. If you use MALLOC() (upper | case), then, upon return, the memory is guaranteed to have been allocated. | What this means is that you can't use MALLOC() anywhere sleeping is | prohibited, i.e. interrupts, mutexes, etc. Is that understanding out of | date or wrong? Does our implementation not conform with that model? MALLOC() is gone (has been for a long time) and its semantics used to be that for a fixed size (evaluated at compile time as a constant) it should be preferred to malloc() because it produced faster code. malloc() remains #define malloc(size, type, flags) kern_malloc(size, flags) but it is implemented as kmem_intr_alloc() that eats a few bytes to store the size, so that free does not need to remember the size. Fixing kmem_alloc() and friends not to fail under certain conditions might be possible, but it could lead to livelock scenarios where everything is stuck in the kernel waiting for resources to be freed. Perhaps we should just explain that it is not the responsibility of the caller to check for the result of kmem_alloc() in the KM_WAIT case, and centralize the check in kmem_alloc() to make it panic() if it would return NULL? Is that better than fixing the 400+ calling sites? christos
