linux-kernel - Re: upcoming kerneloops.org item: get_page_from

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LFD.2.01.0906251317570.3605@localhost.localdomain>
Date:	Thu, 25 Jun 2009 13:22:25 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Theodore Tso <tytso@....edu>
cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	penberg@...helsinki.fi, arjan@...radead.org,
	linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
	npiggin@...e.de
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist

On Thu, 25 Jun 2009, Linus Torvalds wrote:
> 
> Whether these are important to you or not, I dunno. I actually suspect 
> that we might want a combination of "high priority + allow memory 
> freeing", which would be
> 
> 	#define GFP_CRITICAL (__GFP_HIGH | __GFP_WAIT)

Actually, that doesn't work quite the way I intended.

The current page allocator screws up, and doesn't allow us to do this 
(well, you _can_ combine the flags, but they don't mean what they mean on 
their own). If you have the WAIT flag set, the page allocator will not set 
the ALLOC_HARDER bit, so it turns out that GFP_ATOMIC (__GFP_HIGH on its 
own) sometimes actually allows more allocations than the above 
GFP_CRITICAL would.

It might make more sense to make a __GFP_WAIT allocation set the 
ALLOC_HARDER bit _if_ it repeats. The problem with doing a loop of 
allocations outside of the page allocator is that you then miss the 
subtlety of "try increasingly harder" that the page allocator internally 
does (well, right now, the "increasingly harder" only exists for the 
try-to-free path, but we could certainly have it for the try-to-allocate 
side too)

			Linus
--
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/