linux-kernel - Re: [PATCH 2/4] oom: Do not invoke oom notifiers on sysrq+f

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.10.1507091404200.17177@chino.kir.corp.google.com>
Date:	Thu, 9 Jul 2015 14:07:37 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jakob Unterwurzacher <jakobunt@...il.com>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] oom: Do not invoke oom notifiers on sysrq+f

On Thu, 9 Jul 2015, Michal Hocko wrote:

> > Nack, the oom notify list has no place in the oom killer, it should be 
> > called in the page allocator before calling out_of_memory().  
> 
> I cannot say I would like oom notifiers interface. Quite contrary, it is
> just a crude hack. It is living outside of the shrinker interface which is
> what the reclaim is using and it acts like the last attempt before OOM
> (e.g. i915_gem_shrinker_init registers both "shrinkers").

I agree.

> So I am not
> sure it belongs outside of the oom killer proper.
> 

Umm it has nothing to do with oom killing, it quite obviously doesn't 
belong in the oom killer.  It belongs prior to invoking the oom killer if 
memory could be freed.

> Besides that out_of_memory already contains shortcuts to prevent killing
> a task. Why is this any different? I mean why shouldn't callers of
> out_of_memory check whether the task is killed or existing before
> calling out_of_memory?
> 

Because the oom killer is for oom killing and the most vital part of oom 
killing is the granting of memory reserves, otherwise no forward progress 
can be made.

The line between "out of memory" and "not out of memory" is quite clear 
and logic that handles "out of memory" situations belongs in the oom 
killer and logic that handles "not out of memory" situations belongs in 
the page allocator.  This shouldn't be surprising whatsoever, but if you 
insist me moving the code to where it belongs, I will.
--
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/