From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 21:21:09 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0442B5D2 for ; Fri, 12 Oct 2012 21:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA60E8FC17 for ; Fri, 12 Oct 2012 21:21:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 343FEB918; Fri, 12 Oct 2012 17:21:08 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Subject: Re: mmap and resource limits Date: Fri, 12 Oct 2012 17:19:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> In-Reply-To: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210121719.40171.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Oct 2012 17:21:08 -0400 (EDT) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 21:21:09 -0000 On Friday, October 12, 2012 5:11:48 pm Marcel Moolenaar wrote: > > On Oct 12, 2012, at 10:38 AM, John Baldwin wrote: > > > On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: > >> > >> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar 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