Date: Mon, 17 Sep 2012 15:37:19 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Andrey Zonov <zont@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [patch] unprivileged mlock(2) Message-ID: <20120917123719.GS37286@deviant.kiev.zoral.com.ua> In-Reply-To: <50561223.7060709@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> <5046F4E0.6000606@FreeBSD.org> <50561223.7060709@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/Z3Qj54wC++taHdq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 16, 2012 at 09:53:39PM +0400, Andrey Zonov wrote: > On 9/5/12 10:44 AM, Andriy Gapon wrote: > > 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= =20 > >>>> 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 t= he > >>> VM code like alc or your mentor. > >>> > >> > >> Thanks for review! > >> > >>> The code should also be sent for vetoing to security@. Not sure if y= ou > >>> would get a review there, but absence of nays would be good. > >>> > >>> When the code is ready to be committed, please remember about=20 > >>> memorylocked=3Dunlimited in the default entry of the default login.co= nf. 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 th= ey=20 > >> call mlockall(2). ntpd(8) won't, it already raises its RLIMIT_MEMLOCK= =2E I > >> will prepare patches for raising limits if there is no other solution. > >=20 > > Thanks for working on this. > > BTW, I am not sure why those applications would get broken... > > We could/should still have memorylocked=3Dunlimited for the 'root' clas= s. > > Or is it about something else? > >=20 >=20 > Hmm, I thought that root login class commented out. >=20 > >>> 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 > >> > >=20 > > 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. > >=20 >=20 > They are useful for jails as trasz@ mentioned on IRC. >=20 > > P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird. I wonder wh= at was > > the intended use for it (if any)... > >=20 >=20 > So, here is the second version of the patch [1]. >=20 > [1] http://people.freebsd.org/~zont/mlock2.patch In priv_check_cred(), s/to unprivileged/for unprivileged/. In vm_mmap(), on RLIMIT_VMEM failure, racct change shall be rolled back. I am not sure why e.g. sys_obreak() forces racct limits instead of obeing. --/Z3Qj54wC++taHdq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBXGX8ACgkQC3+MBN1Mb4jV1wCcCsv+7MaaB8EUqYJer+Hdx48z E+YAoPN1PxTSYwnFt/ae+XizRl+D97c1 =MriE -----END PGP SIGNATURE----- --/Z3Qj54wC++taHdq--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120917123719.GS37286>