On Fri, Dec 11, 2015 at 09:44:07AM -0500, Greg Troxel wrote: > > Chuck Silvers <c...@chuq.com> writes: > > > how about instead we fix the kmem_alloc() implementation to match the man > > page? > > that seems much more practical to me. adding failure checks and recovery > > code > > to the thousands of *alloc() calls in the kernel would be a vast amount of > > work > > for very little benefit. an attempt to allocate an amount of memory large > > enough that it can never succeed sounds like a bug to me, and it seems > > better > > to fix any such bugs rather than add a vast amount of mostly useless > > error handling code in hopes of papering over them. > > That sounds sensible, but it would seem to require defining some 'small > enough that it cannot fail' size, either statically or via some > getconf-like interface, so that code is only relieved of the obligation > to check if the size is below the limit. Then kernels that can't > enforce that limit have to panic at boot. Did you mean all that, or > something else?
I just meant that kmem_alloc() with KM_SLEEP should never return NULL, so that the caller does not need to check. if the caller is erroneously requesting an amount of memory so large that the allocation can never succeed (eg. more than the RAM in the machine) then kmem_alloc() would need to either retry forever or panic. the internal business that christos mentioned leading to NULL being returned possibly in other cases is a bug too, which ideally would be fixed in the kmem/vmem internals, but papering over that in a single place until we can fix it properly is much better than putting the burden on the caller. -Chuck
