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

[David Rientjes]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/