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]

Date:	Fri, 26 Jun 2009 10:51:30 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Theodore Tso <tytso@....edu>, 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
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist

On Thu, Jun 25, 2009 at 01:22:25PM -0700, Linus Torvalds wrote:
> 
> 
> 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 

No I think it works OK. As designed, at least (whether or not
you agree with the design :P)


> (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,

But it does use ALLOC_HIGH.


> so it turns out that GFP_ATOMIC (__GFP_HIGH on its 
> own) sometimes actually allows more allocations than the above 
> GFP_CRITICAL would.

Yes. The intention was to allow allocations from sleepable/reclaimable
context but not allow them to use up all the reserves allowed for
atomic context (so you don't suddenly get bursts of atomic allocation
failure warnings on your network card when under heavy disk IO, for
example).

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