linux-kernel - Re: Memory overcommit

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.0910301218410.31986@chino.kir.corp.google.com>
Date:	Fri, 30 Oct 2009 12:24:08 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	vedran.furac@...il.com
cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	minchan.kim@...il.com, Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: Memory overcommit

On Fri, 30 Oct 2009, Vedran Furac wrote:

> > The problem you identified in http://pastebin.com/f3f9674a0, however, is a 
> > forkbomb issue where the badness score should never have been so high for 
> > kdeinit4 compared to "test".  That's directly proportional to adding the 
> > scores of all disjoint child total_vm values into the badness score for 
> > the parent and then killing the children instead.
> 
> Could you explain me why ntpd invoked oom killer? Its parent is init. Or
> syslog-ng?
> 

Because it attempted an order-0 GFP_USER allocation and direct reclaim 
could not free any pages.

The task that invoked the oom killer is simply the unlucky task that tried 
an allocation that couldn't be satisified through direct reclaim.  It's 
usually unrelated to the task chosen for kill unless 
/proc/sys/vm/oom_kill_allocating_task is enabled (which SGI requested to 
avoid excessively long tasklist scans).

> > That's the problem, not using total_vm as a baseline.  Replacing that with 
> > rss is not going to solve the issue and reducing the user's ability to 
> > specify a rough oom priority from userspace is simply not an option.
> 
> OK then, if you have a solution, I would be glad to test your patch. I
> won't care much if you don't change total_vm as a baseline. Just make
> random killing history.
> 

The only randomness is in selecting a task that has a different mm from 
the parent in the order of its child list.  Yes, that can be addressed by 
doing a smarter iteration through the children before killing one of them.

Keep in mind that a heuristic as simple as this:

 - kill the task that was started most recently by the same uid, or

 - kill the task that was started most recently on the system if a root
   task calls the oom killer,

would have yielded perfect results for your testcase but isn't necessarily 
something that we'd ever want to see.
--
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/