Date: Fri, 12 Oct 2012 14:11:48 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: mmap and resource limits Message-ID: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> In-Reply-To: <201210121338.28956.jhb@freebsd.org> References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <FD8885CC-6E66-435A-A858-82F41B0F239D@xcllnt.net> <201210121338.28956.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
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)? -- Marcel Moolenaar marcel@xcllnt.nethelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C8FEFC1-35CD-4104-B518-DA32A3EA242C>