From owner-freebsd-arch@FreeBSD.ORG Fri Jun 1 01:46:10 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id A0C471065670; Fri, 1 Jun 2012 01:46:10 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DFD4CB2CE4; Fri, 1 Jun 2012 01:40:43 +0000 (UTC) Message-ID: <4FC81D9C.2080801@FreeBSD.org> Date: Thu, 31 May 2012 18:40:44 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <4FAC3EAB.6050303@delphij.net> <861umkurt8.fsf@ds4.des.no> <20120517055425.GA802@infradead.org> <4FC762DD.90101@FreeBSD.org> In-Reply-To: <4FC762DD.90101@FreeBSD.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=@FreeBSD.ORG, Adrian Chadd , d@delphij.net, Eitan Adler , freebsd-arch@FreeBSD.org, rgrav 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: Fri, 01 Jun 2012 01:46:10 -0000 On 5/31/2012 5:23 AM, Andriy Gapon wrote: > In fact, FreeBSD also has this rlimit and there seems to be full support for it on > both user and kernel sides. > OTOH, PRIV_VM_MLOCK privilege seems to be granted only to the super-user in the > default configuration. And this privilege kind of defeats the limit. > > Perhaps, we should/could kill the privilege and set the limit to a sufficiently > small/safe value for ordinary users? I like this idea, but someone else in the thread (sorry, don't have it handy) brought up the point that we don't want the aggregate of per-user limits to be able to bring down the system either. So the right solution would seem to be a reasonable per-user limit, and a cap on the maximum total amount of locked pages for all unprivileged users, probably based on some percentage of total available memory? Doug -- This .signature sanitized for your protection