linux-kernel - Re: suppress page allocation failure warnings from sys

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.DEB.2.00.1203280007400.16201@chino.kir.corp.google.com>
Date:	Wed, 28 Mar 2012 00:13:51 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Dave Jones <davej@...hat.com>, viro@...iv.linux.org.uk,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: suppress page allocation failure warnings from sys_listxattr

On Tue, 27 Mar 2012, Andrew Morton wrote:

> /*
>  * PAGE_ALLOC_COSTLY_ORDER is the order at which allocations are deemed
>  * costly to service.  That is between allocation orders which should
>  * coelesce naturally under reasonable reclaim pressure and those which
>  * will not.
>  */
> #define PAGE_ALLOC_COSTLY_ORDER 3
> 
> 
> Death to magic numbers :(

This isn't as dire as it sounds, memory compaction is specifically 
targeted to run when the order is greater than this, see 
compaction_ready().  If direct reclaim and compaction both fail then 
there's nothing the VM can do other than oom kill to free memory and we 
avoid doing that because there's no guarantee of freeing enough memory 
that the high-order allocation will be successful.

Not even __GFP_REPEAT is going to be helpful since we can't oom kill 
anything, the only alternative would be to use __GFP_NOFAIL and that would 
just be deadly for such an allocation request.  This error is recoverable, 
so

Acked-by: David Rientjes <rientjes@...gle.com>

to the patch.
--
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/