tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel memory allocation failures



On Fri, Dec 11, 2015 at 09:44:07AM -0500, Greg Troxel wrote:
> 
> Chuck Silvers <chuq%chuq.com@localhost> 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


Home | Main Index | Thread Index | Old Index