[patch] unprivileged mlock(2)

Andrey Zonov zont at FreeBSD.org
Wed Sep 19 09:33:53 UTC 2012


On 9/17/12 4:37 PM, Konstantin Belousov wrote:
> 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 
>>>>>> 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?
>>>
>>
>> Hmm, I thought that root login class commented out.
>>
>>>>> 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.
>>>
>>
>> They are useful for jails as trasz@ mentioned on IRC.
>>
>>> P.S. PRIV_VM_MUNLOCK _privilege_ feels a little bit weird.  I wonder what was
>>> the intended use for it (if any)...
>>>
>>
>> So, here is the second version of the patch [1].
>>
>> [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.
> 

Thanks for review.  Updated patch is here [1].

[1] http://people.freebsd.org/~zont/patches/mlock3.patch

-- 
Andrey Zonov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 535 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120919/54ca89f4/signature.pgp


More information about the freebsd-arch mailing list