linux-kernel - Re: Linux killed Kenny, bastard!

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0901131539050.30953@chino.kir.corp.google.com>
Date:	Tue, 13 Jan 2009 15:43:56 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Evgeniy Polyakov <zbr@...emap.net>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Linux killed Kenny, bastard!

On Wed, 14 Jan 2009, Evgeniy Polyakov wrote:

> Which does not work. Even besides documenation issue, which really means
> that no one really tried to work with it :)
> 

Please.  A lack of thorough documentation, while it should be fixed, does 
not imply that a feature is not being used.

> > Again, your patch _completely_ breaks cpuset oom killing.  That is a 
> > completely separate issue than the memory controller, and it's 
> > disappointing you still don't see it.
> > 
> > In a cpuset constrained oom condition, we do not explicitly exclude all 
> > tasks that are in a disjoint, exclusive cpuset since it's quite possible 
> > that a task has allocated memory outside its cpuset (either because its 
> > cpuset assignment has changed or because its cpuset's mems has changed) 
> > and killing it would free memory in current's cpuset.  We do, however, 
> > prefer to kill a task within the same cpuset; that preference is 
> > implemented in the badness() scoring.
> > 
> > If a task exists on the system in a disjoint, exclusive cpuset that 
> > matches oom_victim_name, your patch will cause it to be killed even though 
> > badness() has penalized it for not sharing a cpuset (dividing its score by 
> > eight).  That probably needlessly killed oom_victim_name since it won't 
> > allow for future memory freeing in the oom-triggering cpuset and the 
> > original oom condition persists.
> 
> It is exactly the purpose of the patch: to kill what is requested to be
> killed.
> 

There are global system-wide oom conditions, cpuset-constrained oom 
conditions, memory controller oom conditions, and mempolicy oom 
conditions.  You're patch affects them all, yet it is quite possible that 
killing oom_victim_name will not alleviate the oom condition in a disjoint 
cpuset.  It would have been needlessly killed because you make no 
distinction on the constraint of the oom.

> I wonder how do you expect users to guess via libastral that even
> adjusted score does not work, since it happens that task is so special,
> that it can not be killed :)
> 
> My knowledge about cpusets is somewhat between zero and void, even more
> I opened mm/kill.c the first time when created a patch (oom-killer is
> not that interesting actually, but it is a matter of taste of course).
> 

Being ignorant about cpusets doesn't justify you breaking their oom 
handling.
--
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/