linux-kernel - Re: [patch 3/3 -mmotm] oom: invoke oom killer for __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: 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.0906031507400.16042@chino.kir.corp.google.com>
Date:	Wed, 3 Jun 2009 15:10:38 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Piggin <npiggin@...e.de>
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mel@....ul.ie>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/3 -mmotm] oom: invoke oom killer for __GFP_NOFAIL

On Tue, 2 Jun 2009, David Rientjes wrote:

> With my patch, we kill a memory hogging task that will free some memory so 
> the allocation will succeed (or multiple tasks if insufficient contiguous 
> memory is available).  Kernel allocations use __GFP_NOFAIL, so the fault 
> of this memory freeing is entirely on the caller, not the page allocator.
> 
> My preference for handling this is to merge my patch (obviously :), and 
> then hopefully deprecate __GFP_NOFAIL as much as possible although I don't 
> suspect it could be eradicated forever.
> 

I really hope this patch isn't getting dropped because it fixes the 
possibility that a __GFP_NOFAIL allocation will fail when its definition 
is to the contrary.  Depending on the size of the allocation, that can 
cause a panic in at least the reiserfs, ntfs, cxgb3, and gfs2 cases.

As I mentioned before, it's a noble goal to deprecate __GFP_NOFAIL as much 
as possible and (at the least) prevent it from trying high-order 
allocation attempts.  The current implementation of the flag is 
problematic, however, and this patch addresses it by attempting to free 
some memory when direct reclaim fails.

This change has already been acked by Rik van Riel in 
http://marc.info/?l=linux-kernel&m=124199910508930 and Mel Gorman in 
http://marc.info/?l=linux-kernel&m=124203850416159.
--
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/