From owner-freebsd-arch@FreeBSD.ORG Wed Sep 5 06:44:53 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 39662106566C; Wed, 5 Sep 2012 06:44:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1CE8FC08; Wed, 5 Sep 2012 06:44:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12987; Wed, 05 Sep 2012 09:44:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T99M2-0002N2-5l; Wed, 05 Sep 2012 09:44:50 +0300 Message-ID: <5046F4E0.6000606@FreeBSD.org> Date: Wed, 05 Sep 2012 09:44:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120901 Thunderbird/15.0 MIME-Version: 1.0 To: Andrey Zonov References: <503DD433.2030108@FreeBSD.org> <201208290906.q7T96C9j032802@gw.catspoiler.org> <20120829092318.GW33100@deviant.kiev.zoral.com.ua> <503F2D24.8050103@FreeBSD.org> <50463026.8000506@FreeBSD.org> <504653CD.2000707@FreeBSD.org> In-Reply-To: <504653CD.2000707@FreeBSD.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org 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, 05 Sep 2012 06:44:53 -0000 on 04/09/2012 22:17 Andrey Zonov said the following: > On 9/4/12 8:45 PM, Andriy Gapon wrote: >> on 30/08/2012 12:06 Andrey Zonov said the following: >>> Hi, >>> >>> So, I've got the first version of the patch (attached) which fixes >>> memory locked limit checking and accounting. >> >> Andrey, >> >> your mlock.patch looks good to me, but I haven't verified pieces under >> RACCT. Please try to get a review from a person who is knee-deep in the >> VM code like alc or your mentor. >> > > Thanks for review! > >> The code should also be sent for vetoing to security@. Not sure if you >> would get a review there, but absence of nays would be good. >> >> When the code is ready to be committed, please remember about >> memorylocked=unlimited in the default entry of the default login.conf. A >> big warning about it will have to be posted (in UPDATING and >> current@/stable@ at the very least). >> > > After that amd(8), geli(8) and watchdogd(8) will be broken, because they > call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLOCK. I > will prepare patches for raising limits if there is no other solution. Thanks for working on this. BTW, I am not sure why those applications would get broken... We could/should still have memorylocked=unlimited for the 'root' class. Or is it about something else? >> Thank you very much for doing this work. >> >> P.S. It would probably make sense to provide some HTTP home for this >> patch as well. >> > > Updated patch is here [1]. > > [1] http://people.freebsd.org/~zont/mlock1.patch > Thank you! One additional thing - we probably should retire PRIV_VM_MLOCK and PRIV_VM_MUNLOCK. That would include making changes to sys/i386/ibcs2/ibcs2_misc.c and sys/ofed/drivers/infiniband/core/umem.c. P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder what was the intended use for it (if any)... -- Andriy Gapon