linux-kernel - Re: [discuss] memrlimit - potential applications that can use

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:	Tue, 19 Aug 2008 22:15:52 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
CC:	Paul Menage <menage@...gle.com>, Dave Hansen <haveblue@...ibm.com>,
	Andrea Righi <righi.andrea@...il.com>,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [discuss] memrlimit - potential applications that can use

Dave Hansen wrote:
> On Tue, 2008-08-19 at 12:48 +0530, Balbir Singh wrote:
>> 1. To provide a soft landing mechanism for applications that exceed their memory
>> limit. Currently in the memory resource controller, we swap and on failure OOM.
>> 2. To provide a mechanism similar to memory overcommit for control groups.
>> Overcommit has finer accounting, we just account for virtual address space usage.
>> 3. Vserver will directly be able to port over on top of memrlimit (their address
>> space limitation feature)
> 
> Balbir,
> 
> This all seems like a little bit too much hand waving to me.  I don't

Dave, there is no hand waving, just an honest discussion. Although, you may not
see it in the background, we still need overcommit protection and we have it
enabled by default for the system. There are applications that can deal with the
constraints setup by the administrator and constraints of the environment,
please see http://en.wikipedia.org/wiki/Autonomic_computing.

> really see a single concrete user in the "potential applications" here.
> I really don't understand why you're pushing this so hard if you don't
> have anyone to actually use it.
> 
> I just don't see anyone that *needs* it.  There's a lot of "it would be
> nice", but no "needs".

If you see the original email, I've sent - I've mentioned that we need
overcommit support (either via memrlimit or by porting over the overcommit
feature) and the exploiters you are looking for is the same as the ones who need
overcommit and RLIMIT_AS support.

On the memory overcommit front, please see PostgreSQL Server Administrator's
Guide at
http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html

The guide discusses turning off memory overcommit so that the database is never
OOM killed, how do we provide these guarantees for a particular control group?
We can do it system wide, but ideally we want the control point to be per
control group.

As far as other users are concerned, I've listed users of the memory limit
feature, in the original email I sent out. To try and understand your viewpoint
better, could you please tell me if

1. You are opposed to overcommit and RLIMIT_AS as features

OR

2. Expanding them to control groups

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