Date: Fri, 12 Oct 2012 17:19:40 -0400 From: John Baldwin <jhb@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-arch@freebsd.org Subject: Re: mmap and resource limits Message-ID: <201210121719.40171.jhb@freebsd.org> In-Reply-To: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, October 12, 2012 5:11:48 pm Marcel Moolenaar wrote: > > On Oct 12, 2012, at 10:38 AM, John Baldwin <jhb@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@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)? The one thought I had was to have a RLIMIT_ANON perhaps which limits the amount of MAP_ANON memory a process uses. This would be mostly equivalent to RLIMIT_DATA. Note that rtld uses its own private pool of MAP_ANON pages for an internal malloc, so that would be part of this limit as well. This limit would be checked at mmap() time, so things like anonymous pages due to COW mappings on MAP_PRIVATE mappings wouldn't count against it. However, to catch programs with a memory leak using a MAP_ANON-backed malloc() similar to RLIMIT_DATA it would probably work. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210121719.40171.jhb>