From owner-freebsd-arch@FreeBSD.ORG Wed Aug 29 12:25:46 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 37B45106566C; Wed, 29 Aug 2012 12:25:46 +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 0C5788FC08; Wed, 29 Aug 2012 12:25:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 60DD1B91A; Wed, 29 Aug 2012 08:25:45 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 29 Aug 2012 07:41:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503CF3B1.3050604@FreeBSD.org> In-Reply-To: <503CF3B1.3050604@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208290741.59143.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Aug 2012 08:25:45 -0400 (EDT) Cc: Andrey Zonov , Robert Watson Subject: Re: [patch] unprivileged mlock(2) 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: Wed, 29 Aug 2012 12:25:46 -0000 On Tuesday, August 28, 2012 12:37:05 pm Andrey Zonov wrote: > Hi, > > We've got RLIMIT_MEMLOCK for years, but this limit is useless, because > only root may call mlock(2), and root may raise any limits. > > I suggest patch that allows to call mlock(2) for unprivileged users. > Are there any objections to got it in tree? Aside from the other comments (e.g. needing to fix MCL_FUTURE to honor the limit), if you were to keep the unprivileged_mlock variable, I think the right place to patch this would be in kern_priv.c by adding a new check to grant PRIV_VM_MLOCK and PRIV_VM_MUNLOCK to all users if unprivileged_mlock is set. This centralizes the privilege checking logic instead of duplicating it in four different places. Robert may have a different opinion, however. -- John Baldwin