From owner-freebsd-arch@FreeBSD.ORG Fri Oct 12 21:11:55 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 40EC7350; Fri, 12 Oct 2012 21:11:55 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 198DE8FC12; Fri, 12 Oct 2012 21:11:54 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q9CLBrgX068367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Oct 2012 14:11:54 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: mmap and resource limits From: Marcel Moolenaar In-Reply-To: <201210121338.28956.jhb@freebsd.org> Date: Fri, 12 Oct 2012 14:11:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8FEFC1-35CD-4104-B518-DA32A3EA242C@xcllnt.net> References: <83AE27A6-C844-4720-99E7-A12106F77227@xcllnt.net> <201210121338.28956.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1499) 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:11:55 -0000 On Oct 12, 2012, at 10:38 AM, John Baldwin wrote: > On Friday, October 12, 2012 12:04:19 pm Marcel Moolenaar wrote: >>=20 >> On Oct 8, 2012, at 10:40 AM, Marcel Moolenaar = 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