linux-kernel - OOM policy, overcommit control, and soft limits

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-next>] [day] [month] [year] [list]

Message-ID: <20080531102752.GA25244@foursquare.net>
Date:	Sat, 31 May 2008 06:27:52 -0400
From:	Chris Frey <cdfrey@...rsquare.net>
To:	linux-kernel@...r.kernel.org
Subject: OOM policy, overcommit control, and soft limits

Hi,

The kernel provides things like ulimit, overcommit_memory, and the OOM
killer notifications, so in theory memory management should not be a
problem, but from time to time, I have a real need to regain control of
my system when it runs away on me.

I like how mode 2 of overcommit_memory uses the ratio as a boundary limit.
Ideally I would like something like this as a soft limit, so once the
system gets that full, I get a warning.

Here's my ideal OOM flow:

	1) set my soft limit to 90% of RAM

	2) any malloc that hits this limit first runs through a notification
		hook, that talks to a userspace daemon if present,
		or just denies the malloc if not

	3) the daemon can decide whether to allow the allocation, going
		beyond the soft limit

	4) the daemon can make these decisions automatically based on
		policy (i.e. X always gets the green light), or if we
		want to get fancy it can talk to some pre-allocated
		GUI to present the decision to the user...
		(i.e. Allocate / Deny / Stop / Kill)

	5) if the user foolishly keeps allocating, then the current
		OOM killer comes into play

I'm sure someone has thought of this before me.  Does anything remotely
similar to this already exist?  I've googled for OOM policy, but so far
all I've seen is Rusty Lynch's patch from 2003, and really, I want this
behaviour to happen when there is still a bit of memory left, so things
can be dealt with before they are OOM-level dire.

Thanks in advance,
- Chris

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