linux-kernel - Re: user defined OOM policies

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: <20131119134007.GD20655@dhcp22.suse.cz>
Date:	Tue, 19 Nov 2013 14:40:07 +0100
From:	Michal Hocko <mhocko@...e.cz>
To:	linux-mm@...ck.org
Cc:	Greg Thelen <gthelen@...gle.com>,
	Glauber Costa <glommer@...il.com>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	Joern Engel <joern@...fs.org>, Hugh Dickins <hughd@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: user defined OOM policies

On Tue 19-11-13 14:14:00, Michal Hocko wrote:
[...]
> We have basically ended up with 3 options AFAIR:
> 	1) allow memcg approach (memcg.oom_control) on the root level
>            for both OOM notification and blocking OOM killer and handle
>            the situation from the userspace same as we can for other
> 	   memcgs.

This looks like a straightforward approach as the similar thing is done
on the local (memcg) level. There are several problems though.
Running userspace from within OOM context is terribly hard to do
right. This is true even in the memcg case and we strongly discurage
users from doing that. The global case has nothing like outside of OOM
context though. So any hang would blocking the whole machine. Even
if the oom killer is careful and locks in all the resources it would
have hard time to query the current system state (existing processes
and their states) without any allocation.  There are certain ways to
workaround these issues - e.g. give the killer access to memory reserves
- but this all looks scary and fragile.

> 	2) allow modules to hook into OOM killer path and take the
> 	   appropriate action.

This already exists actually. There is oom_notify_list callchain and
{un}register_oom_notifier that allow modules to hook into oom and
skip the global OOM if some memory is freed. There are currently only
s390 and powerpc which seem to abuse it for something that looks like a
shrinker except it is done in OOM path...

I think the interface should be changed if something like this would be
used in practice. There is a lot of information lost on the way. I would
basically expect to get everything that out_of_memory gets.

> 	3) create a generic filtering mechanism which could be
> 	   controlled from the userspace by a set of rules (e.g.
> 	   something analogous to packet filtering).

This looks generic enough but I have no idea about the complexity.
-- 
Michal Hocko
SUSE Labs
--
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/