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:	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ