linux-kernel - Re: [patch 4/7 -mm] oom: badness heuristic rewrite

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, 15 Feb 2010 13:54:39 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Minchan Kim <minchan.kim@...il.com>
cc:	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Nick Piggin <npiggin@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Lubos Lunak <l.lunak@...e.cz>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch 4/7 -mm] oom: badness heuristic rewrite

On Sat, 13 Feb 2010, Minchan Kim wrote:

> > The oom killer is not the appropriate place for a kernel forkbomb policy
> > to be implemented, you'd need to address that concern in the scheduler.
> 
> I agree. but your's patch try to implement policy(avg rss of children < HZ)
> in oom killer as well as detection.
> so I pointed out that.

That's not what's used, we detect whether a child should be included in 
the forkbomb count by checking for two traits: (i) it doesn't share an 
->mm with the parent, otherwise it wouldn't free any memory unless the 
parent was killed as well, and (ii) its total runtime is less than a 
second since threads in forkbomb scenarios don't typically get any 
runtime.  The _penalization_ is then the average rss of those children 
times how many times the count exceeds oom_forkbomb_thres.

> I think if we want to implement it, we also consider above scenario.
> As you said, it would be better to detect forkbom in scheduler.
> Then, let's remove forkbomb detection in OOM killer.
> Afterward, we can implement it in scheduler and can use it in OOM killer.
> 

We're not enforcing a global, system-wide forkbomb policy in the oom 
killer, but we do need to identify tasks that fork a very large number of 
tasks to break ties with other tasks: in other words, it would not be 
helpful to kill an application that has been running for weeks because 
another application with the same or less memory usage has forked 1000 
children and has caused an oom condition.  That unfairly penalizes the 
former application that is actually doing work.

Again, I'd encourage you to look at this as only a slight penalization 
rather than a policy that strictly needs to be enforced.  If it were 
strictly enforced, it would be a prerequisite for selection if such a task 
were to exist; in my implementation, it is part of the heuristic.

> > That doesn't work with Rik's example of a webserver that forks a large
> > number of threads to handle client connections.  It is _always_ better to
> > kill a child instead of making the entire webserver unresponsive.
> 
> In such case, admin have to handle it by oom_forkbom_thres.
> Isn't it your goal?
> 

oom_forkbomb_thres has a default value, which is 1000, so it should be 
enabled by default.

> My suggestion is how handle buggy forkbomb processes which make
> system almost hang by user's mistake. :)
> 

I don't think you've given a clear description (or, even better, a patch) 
of your suggestion.