Messages in this thread | | | Date | Sun, 3 May 2009 02:53:34 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH -tip] x86: uv - prevent NULL dereference in uv_system_init |
| |
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.
| |