linux-kernel - Re: [patch 6/7] oom: move oom_adj value from task_struct to mm

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:	Tue, 5 May 2009 11:29:52 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Nick Piggin <npiggin@...e.de>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	San Mehat <san@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 6/7] oom: move oom_adj value from task_struct to
 mm_struct

On Tue, 5 May 2009, Nick Piggin wrote:

> Hmm, not particularly bad to do any of this, but I guess the way to
> do it without changing userspace APIs would be to take the lowest
> value of oomkilladj for any thread in the mm and use that.
> 

Then /proc/pid/oom_adj (and, thus, what /proc/pid/oom_score reports) will 
be inconsistent.  In other words, it would be possible for a task to have 
an oom_adj value of +15, meaning to prefer killing it above all others, 
and it turns out to be immune from oom killing because it shares memory 
with an OOM_DISABLE task.  You could argue that's broken in userspace, but 
this patchset actually makes oom_adj values a trait of the memory it 
represents rather than the task itself so not only is it consistent but it 
doesn't cause any surprises when your system (or memcg or cpuset) is oom.

Taking the lowest oom_adj value would also require more than one expensive 
tasklist scan or an internal oom killer stack of eligible tasks to kill so 
we can pop a task that shares ineligible memory and still kill a task that 
has a higher priority as defined by the user.

> I guess the previous behaviour was basically quite random anyway if
> multiple threads each have different oomkilladj variables so it
> probably doesn't matter.
> 

Exactly, and this is what the patchset addresses: oom_adj values become a 
trait of the memory it describes and not tasks that may happen to share 
it.  It also fixes a livelock if the highest priority task actually can't 
be killed because it shares memory with an OOM_DISABLE task.

> I don't suppose you'd ever get a significantly advanced (aka crazy)
> userspace app that would want to deliberately set *one* of its threads
> as OOM_DISABLE and others allowed to be killed, would we?
> 

You could argue that's totally broken in userspace, but there's no reason 
for the kernel to not expose a consistent API that describes the actual 
oom priority.  oomkilladj really is inappropriate as a per task value.
--
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/