linux-kernel - Re: [PATCH] copy over oom

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.0907202030400.25770@chino.kir.corp.google.com>
Date:	Mon, 20 Jul 2009 20:40:41 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Menage <menage@...gle.com>
cc:	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, mel@....ul.ie, npiggin@...e.de
Subject: Re: [PATCH] copy over oom_adj value at fork time

On Mon, 20 Jul 2009, Paul Menage wrote:

> > My patches don't merely address threads that have an oom_adj value of
> > OOM_DISABLE while others sharing the same memory do not, they address a
> > consistency issue whereas those threads may all share memory but have
> > radically different oom_adj values: that means that only the highest
> > oom_adj value amongst them is actually used by the oom killer and all
> > other oom_adj values set by the user for those threads are wrong.
> 
> But these patches change an API that has existed for at least 4 years
> (i.e. before git history exists) and the change is known to break some
> apps that relied on the existing API.

Such applications (none have been mentioned) should be modified to comply 
with how the oom killer uses oom_adj values, which is identical for all 
tasks sharing the same mm_struct.  That prevents inconsistent states such 
as being able to elevate /proc/pid/oom_adj to 16 so that pid is targeted 
first because of its massive /proc/pid/oom_score when, in actuality, it 
may be OOM_DISABLE because it shares memory with an OOM_DISABLE parent and 
cannot be killed.  It is inappropriate for the kernel to report completely 
erroneous oom scores, which the old behavior allowed, so the end result is 
your userspace will need to be fixed.
--
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/