In article <20160215212942.ga7...@spathi.chuq.com>,
Chuck Silvers <c...@chuq.com> wrote:
>-=-=-=-=-=-
>
>On Fri, Dec 11, 2015 at 12:16:19PM -0500, Christos Zoulas wrote:
>> On Dec 11, 8:54am, c...@chuq.com (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
