linux-kernel - Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they are OOM-unkillable.

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:	Mon, 22 Feb 2016 17:06:29 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	akpm@...ux-foundation.org, mgorman@...e.de, oleg@...hat.com,
	torvalds@...ux-foundation.org, hughd@...gle.com, andrea@...nel.org,
	riel@...hat.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm,oom: exclude oom_task_origin processes if they
 are OOM-unkillable.

On Thu, 18 Feb 2016, Michal Hocko wrote:

> > Anyway, this is NACK'd since task->signal->oom_score_adj is checked under 
> > task_lock() for threads with memory attached, that's the purpose of 
> > finding the correct thread in oom_badness() and taking task_lock().  We 
> > aren't going to duplicate logic in several functions that all do the same 
> > thing.
> 
> Is the task_lock really necessary, though? E.g. oom_task_origin()
> doesn't seem to depend on it for task->signal safety. If you are
> referring to races with changing oom_score_adj does such a race matter
> at all?
> 

oom_badness() ranges from 0 (don't kill) to 1000 (please kill).  It 
factors in the setting of /proc/self/oom_score_adj to change that value.  
That is where OOM_SCORE_ADJ_MIN is enforced.  It is also needed in 
oom_badness() to determine whether a child process should be sacrificed 
for its parent.  We don't add duplicate logic everywhere if you want the 
code to be maintainable; the only exception would be for performance 
critical code which the oom killer most certainly is not.

I'm simply not entertaining any patch to the oom killer that duplicates 
code everywhere, increases its complexity, makes it grow in text size, and 
makes it more difficult to maintain.