linux-kernel - Re: [PATCH 1/5] mm: Add __GFP_NO_OOM

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]

Message-ID: <alpine.DEB.2.00.0905071439370.24404@chino.kir.corp.google.com>
Date:	Thu, 7 May 2009 14:46:34 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Andrew Morton <akpm@...ux-foundation.org>, fengguang.wu@...el.com,
	linux-pm@...ts.linux-foundation.org, pavel@....cz,
	torvalds@...ux-foundation.org, jens.axboe@...cle.com,
	alan-jenkins@...fmail.co.uk, linux-kernel@...r.kernel.org,
	kernel-testers@...r.kernel.org
Subject: Re: [PATCH 1/5] mm: Add __GFP_NO_OOM_KILL flag

On Thu, 7 May 2009, Rafael J. Wysocki wrote:

> > The fact is that _all_ allocations here are implicitly __GFP_NO_OOM_KILL 
> > whether it specifies it or not since the oom killer would simply kill a 
> > task in D state which can't exit or free memory and subsequent allocations 
> > would make the oom killer a no-op because there's an eligible task with 
> > TIF_MEMDIE set.  The only thing you're saving with __GFP_NO_OOM_KILL is 
> > calling the oom killer in a first place and killing an unresponsive task 
> 
> That's exactly what we're trying to do.  We don't want tasks to get killed just
> because we're freeing memory for hibernation image.
> 

Then, again, why can't you just lock out the oom killer as I suggested if 
__GFP_NO_OOM_KILL is actually implied for all allocations when 
preallocating?  It prevents adding an unnecessary gfp flag, sprinkling it 
around in the hibernation code, and a comment would actually explain why 
it's the right thing to do (i.e. no other threads other than kthreads 
could possibly be executing the oom killer and if they are oom then we'll 
have to kill a userspace task anyway when thawed).

> > but that would have to happen anyway when thawed since the system is oom 
> > (or otherwise lockup for GFP_KERNEL with order < PAGE_ALLOC_COSTLY_ORDER).
> 
> Are you sure?  The image memory is freed before thawing tasks.
> 

If you try to allocate any non-__GFP_NORETRY memory such as GFP_KERNEL 
with order < PAGE_ALLOC_COSTLY_ORDER and direct reclaim cannot free memory 
(and the oom killer is implicitly a no-op whether you specify 
__GFP_NO_OOM_KILL or not), then you could loop endlessly in the page 
allocator.  When allocating GFP_IMAGE you need to ensure that can't happen 
and __GFP_NORETRY may not be your best option because it could fail 
unnecessarily when reclaim could have helped.
--
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/