linux-kernel - Re: [PATCH -tip] mm: introduce __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 May 2009 23:11:11 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>,
	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Rik van Riel <riel@...hat.com>,
	David Rientjes <rientjes@...gle.com>,
	Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [PATCH -tip] mm: introduce __GFP_PANIC modifier

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