Date: Wed, 05 Sep 2012 09:44:48 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Andrey Zonov <zont@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: [patch] unprivileged mlock(2) Message-ID: <5046F4E0.6000606@FreeBSD.org> In-Reply-To: <504653CD.2000707@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5046F4E0.6000606>