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
| ||
|
Date: Thu, 29 Oct 2009 12:53:42 -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 Thu, 29 Oct 2009, Vedran Furac wrote: > But then you should rename OOM killer to TRIPK: > Totally Random Innocent Process Killer > The randomness here is the order of the child list when the oom killer selects a task, based on the badness score, and then tries to kill a child with a different mm before the parent. 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. 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. > If you have OOM situation and Xorg is the first, that means it's leaking > memory badly and the system is probably already frozen/FUBAR. Killing > krunner in that situation wouldn't do any good. From a user perspective, > nothing changes, system is still FUBAR and (s)he would probably reboot > cursing linux in the process. > It depends on what you're running, we need to be able to have the option of protecting very large tasks on production servers. Imagine if "test" here is actually a critical application that we need to protect, its not solely mlocked anonymous memory, but still kill if it is leaking memory beyond your approximate 2.5GB. How do you do that when using rss as the baseline? -- 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/
Powered by blists - more mailing lists