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: 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.0905071337400.6598@chino.kir.corp.google.com>
Date:	Thu, 7 May 2009 13:40:29 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Pavel Machek <pavel@....cz>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	fengguang.wu@...el.com, linux-pm@...ts.linux-foundation.org,
	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, Pavel Machek wrote:

> > Third time I'm going to suggest this, and I'd like a response on why it's 
> > not possible instead of being ignored.
> > 
> > All of your tasks are in D state other than kthreads, right?  That means 
> > they won't be in the oom killer (thus no zones are oom locked), so you can 
> > easily do this
> 
> Well, OOM killer may be running on behalf of some kthread at that
> point....? Quite unlikely, but possible AFAICT.

The oom killer doesn't care about the task's state, so this will be a 
genuine oom situation where it will kill a task (one in D state since 
kthreads are inherently immune) which will die when unfrozen.  That would 
have had to happen anyway when all tasks wake up since the system is 
completely out of memory (except for kswapd that is given access to memory 
reserves because of PF_MEMALLOC) so you're not worried about completely 
blocking out the oom killer anymore because the next kthread to invoke it 
in such a situation will end up being a no-op because it finds a task with 
TIF_MEMDIE set.
--
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/