mmap and resource limits

[Marcel Moolenaar]

On Oct 12, 2012, at 10:38 AM, John Baldwin <jhb at FreeBSD.org> wrote:

> On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote:
>> 
>> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar <marcel at xcllnt.net> wrote:
>> 
>>> All,
>>> 
>>> What's the progress of mmap(2) doing resource accounting and
>>> it respecting resource limits?
>> 
>> *silence*
>> 
>> Ok, so no new progress. We're still not doing it and we don't
>> have an idea of how we want to do it if or when we're going to
>> want to do it. Consequently: we still need brk()/sbrk().
>> 
>> Correct assessment?
> 
> Well.  You can use RLIMIT_AS, but that includes anything you map, not just 
> malloc().  The problem is that even if you use sbrk() and rely on RLIMIT_DATA, 
> any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get around 
> that.

Wouldn't it be a good approach then to enforce RLIMIT_AS as the
external (to the process) limit and define RLIMIT_DATA et al
as internal (to the process) resources as a way to have the
process put limits on particular types of memory and do so on
a voluntary basis?

I mean, RLIMIT_STACK is impossible to enforce in multi-threaded
processes. RLIMIT_CODE is already convoluted by having R/O data
in the same segment. RLIMIT_DATA... well...

So, have processes give meaning to them in whatever way makes
sense to the process and have the kernel limit it "FWIW"?

Any thoughts on the best way for a process can tell the kernel
how to treat a memory region (i.e. data, stack or code)?

-- 
Marcel Moolenaar
marcel at xcllnt.net