[patch] unprivileged mlock(2)

[Andriy Gapon]

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 at .  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