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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar <marcel@xcllnt.net> = wrote: >>=20 >>> All, >>>=20 >>> What's the progress of mmap(2) doing resource accounting and >>> it respecting resource limits? >>=20 >> *silence* >>=20 >> 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(). >>=20 >> Correct assessment? >=20 > Well. You can use RLIMIT_AS, but that includes anything you map, not = just=20 > malloc(). The problem is that even if you use sbrk() and rely on = RLIMIT_DATA,=20 > any misbehaving app can just use mmap(MAP_ANON) or shm_open() to get = around=20 > 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)? --=20 Marcel Moolenaar marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C8FEFC1-35CD-4104-B518-DA32A3EA242C>