Re: kernel memory allocation failures

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 11,  7:25am, buhrow%nfbcal.org@localhost (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