Re: [PATCH -tip] x86: uv - prevent NULL dereference in uv_system_init

David Rientjes
2009-05-03T09:53:56Z

On Sun, 3 May 2009, Cyrill Gorcunov wrote:

> What if instead of tear thru all these cases we implement
> a special wrapper (say kmalloc_panic)? Almost the same
> are done for bootmem allocator (__alloc_bootmem_nopanic).
>

This is certainly what would be required to avoid a largely unnecessary
conditional in a very hot path. __GFP_PANIC couldn't be implemented any
lower than the kmalloc() functions if it is to be consistency because this
is the only point where we decide whether to go through the slab allocator
or do pass-through to the page allocator (SLUB_MAX_SIZE in slub). With
the work currently being done to make the page allocator faster,
SLUB_MAX_SIZE is bound to be reduced at some point.

> It seems __GFP_PANIC would not be that popular anyway
> and what is more important -- we would add additional
> check the flag somewhere inside mm code (which will
> be not needed most the time).
>

The advantage of implementing your kmalloc_panic() idea is that it
provides a centralized place where diagostic information could be emitted
that shows, for instance, the allocation order and gfp flags for code
paths where it isn't immediately obvious. Even with that information,
however, it doesn't provide any additional insight that could help to fix
the problem other than insufficient memory of that type and order.

I don't think it's worth implementing the necessary variations just to
panic on NULL such as kmalloc_node, etc.