linux-kernel - Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling

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:	Sun, 31 Jan 2010 21:29:33 +0100
From:	Vedran Furač <vedran.furac@...il.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	minchan.kim@...il.com, Balbir Singh <balbir@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling

David Rientjes wrote:

> On Sat, 30 Jan 2010, Vedran Furac wrote:
> 
>>> The oom killer has been doing this for years and I haven't noticed a huge 
>>> surge in complaints about it killing X specifically because of that code 
>>> in oom_kill_process().
>> Well you said it yourself, you won't see a surge because "oom killer has
>> been doing this *for years*". So you'll have a more/less constant number
>> of complains over the years. Just google for: linux, random, kill, memory;
> 
> You snipped the code segment where I demonstrated that the selected task 
> for oom kill is not necessarily the one chosen to die: if there is a child 
> with disjoint memory that is killable, it will be selected instead.  If 
> Xorg or sshd is being chosen for kill, then you should investigate why 
> that is, but there is nothing random about how the oom killer chooses 
> tasks to kill.

I know that it isn't random, but it sure looks like that to the end user
and I use it to emphasize the problem. And about me investigating, that
simply not possible as I am not a kernel hacker who understands the code
beyond the syntax level. I can only point to the problem in hope that
someone will fix it.

> The facts that you're completely ignoring are that changing the heuristic 
> baseline to rss is not going to prevent Xorg or sshd from being selected 

In my tests a simple "ps -eo rss,command --sort rss" always showed the
cuprit, but OK, find another approach in fixing the problem in hope for
a positive review. Just... I feel everything will be put under the
carpet with fingers in ears while singing everything is fine. Prove me
wrong.

Regards,
Vedran


-- 
http://vedranf.net | a8e7a7783ca0d460fee090cc584adc12

View attachment "vedran_furac.vcf" of type "text/x-vcard" (220 bytes)