Re: [PATCH -tip] mm: introduce __GFP_PANIC modifier

[Cyrill Gorcunov <gorcunov@gmail.com>]

[Christoph Lameter - Mon, May 04, 2009 at 11:54:53AM -0400]
| On Mon, 4 May 2009, Cyrill Gorcunov wrote:
| 
| > You know I only found a message in case if page is already
| > not granted (ie NULL is going to be returned) and right
| > before that we print a warning about that (nopage: label).
| > Which means - no panic here and with (__GFP_NOFAIL | __GFP_REPEAT)
| > just spinning around in attepmt to allocate new memory. And how
| > to behave on atomic allocations. Almost give up... :)
| 
| Could you check for __GFP_FAIL|__GFP_REPEAT somewheres and panic? Not sure
| if __GFP_REPEAT is the right second flag to use.
| 

Well Christoph I've checked those flags (and though for some
max fail iterations counter as well which was then refused).
None of combination seems to satisfy this requirement (don't
return NULL on out-of-memory but panic instead) in clear way.
There is a question remains opened how to behave on a case if
allocation was atomic. Just dunno.

If it is critical to not bring new __GFP_PANIC then
I could be just using __GFP_NOFAIL and nofity a user via
printk that we're in stage of allocating memory (anyway
it looks strange that we have a number of callers with
__GFP_NOFAIL with BUG_ON/if-checks following. But I could
me missing).

	-- Cyrill