From owner-freebsd-arch@FreeBSD.ORG Thu May 17 09:59:55 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74341065675; Thu, 17 May 2012 09:59:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6488FC08; Thu, 17 May 2012 09:59:55 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4H9xSqD022100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 May 2012 19:59:29 +1000 Date: Thu, 17 May 2012 19:59:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Artem Belevich In-Reply-To: Message-ID: <20120517193904.X1317@besplex.bde.org> References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-102633144-1337248768=:1317" Cc: Eitan Adler , Adrian Chadd , freebsd-arch@freebsd.org, d@delphij.net, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Allow small amount of memory be mlock()'ed by unprivileged process? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 09:59:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-102633144-1337248768=:1317 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 16 May 2012, Artem Belevich wrote: > On Wed, May 16, 2012 at 3:36 PM, Eitan Adler wrote= : >> On 16 May 2012 18:32, Adrian Chadd wrote: >>> .. what's to stop a fork() bomb from grabbing all pages? >> >> + possibly limiting the number of pages per user, =E0 la >> maxprocperuid. > > Shouldn't RLIMIT_NPROC already limit the damage? Products of limits are too large to actually be useful as limits in most cases. RLIMIT_NPROC usually gives the same limit as maxprocperuid. E.g., on 2 very different systems I have handy both are 5547. Then the open file limit is 11095 on the smaller system (1GB RAM) and 3000 on the larger system (2GB RAM). The product of 5507 and 11095 is > 58M. There is no way the data structures for that many files can fit in 1GB RAM. So the limit is enough for normal operation but is useless for defending against fork bombs. Even if you have a small limit on the number of pages per user and a small number of users, the product may be large, and vm needs to reserve this number of pages so that it doesn't run out when doing more-critical operations. It might be able to preserve its reservations (v_free_reserved, v_pageout_fre_min and v_interrupt_free_min) by reducing the limit on the number of locked pages for each user and all users when under pressure, but then unprivileged pages that have already grabbed and locked pages could damage privileged processes later. Bruce --0-102633144-1337248768=:1317--