Re: kernel memory allocation failures

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

In article <20160215212942.GA7372%spathi.chuq.com@localhost>,
Chuck Silvers  <chuq%chuq.com@localhost> wrote:
>-=-=-=-=-=-
>
>On Fri, Dec 11, 2015 at 12:16:19PM -0500, Christos Zoulas wrote:
>> On Dec 11,  8:54am, chuq%chuq.com@localhost (Chuck Silvers) wrote:
>> -- Subject: Re: kernel memory allocation failures
>> 
>> | I haven't looked see exactly what the internal conditions are that lead to
>> | kmem_alloc(KM_SLEEP) returning NULL, so it's not clear whether having
>> | kmem_alloc() retry or panic in that situation would be better.
>> | but either of those would be better than adding code to all the callers.
>> 
>>     http://nxr.netbsd.org/xref/src/sys/kern/subr_vmem.c#256
>> 
>> Where we are calling the pool code with PR_NOWAIT and the flags are not paid
>> attention to at all (except in the recursive calls).
>
>the attached patch makes bt_alloc() retry the bt_refill() when called
>with VM_SLEEP,
>which I think removes all the ways that vmem_alloc() with VM_SLEEP
>(and thus kmem_alloc() with KM_SLEEP) can fail.
>
>
>> And there is also:
>> 
>>     http://nxr.netbsd.org/xref/src/sys/kern/subr_vmem.c#272
>> 
>> where the 3 bt_refill() calls are not even being checked (but at least
>> they use flags :-)
>
>the error is not checked because these are just a precaution,
>the function will not do anything different if these fail.
>I'll cast them to void.
>
>
>I'll commit this patch in a few days if there are no complaints.
>

Sure LGTM. Why don't you create a define for:

#define VM_RESIZEFLAGS(flags) \
    (((flags) & ~VM_FITMASK) | VM_INSTANTFIT | VM_POPULATING)

christos