Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2012 14:57:33 +0400
From:      Andrey Zonov <zont@FreeBSD.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r244383 - head/etc
Message-ID:  <50D19D9D.9090200@FreeBSD.org>
In-Reply-To: <alpine.BSF.2.00.1212180951260.22858@fledge.watson.org>
References:  <201212180727.qBI7Rp0t084371@svn.freebsd.org> <alpine.BSF.2.00.1212180948190.22858@fledge.watson.org> <alpine.BSF.2.00.1212180951260.22858@fledge.watson.org>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On 12/18/12 1:51 PM, Robert Watson wrote:
> 
> On Tue, 18 Dec 2012, Robert Watson wrote:
> 
>>> Log:
>>>  - Set memorylocked limit to 64Kb for default login class.
>>>    This prevents unprivileged users to lock too much memory.
>>>  - Set memorylocked limit to 64Mb for daemon login class.
>>>    Some daemons such as amd(8) and watchdogd(8) calls mlockall(2) on
>>>    startup, they are run from init(8) which uses daemon login class.
>>>  - Set memorylocked limit to unlimited for root login class.
>>>
>>>  Suggested by:    avg
>>>  Approved by:    kib (mentor)
>>>  MFC after:    1 week
>>
>> I think you should not MFC this one quickly -- let's wait for it to
>> shake out in the -CURRENT userbase for a few months to see what
>> breaks.  I wouldn't be surprised if a fair number of applications
>> (both publicly available, and local at various FreeBSD-using shops)
>> are implicitly depending on their not being limits to memorylocked by
>> default.  After an upgrade, they might find that their applications
>> simply stop working for potentially hard-to-debug reasons.
>>
>> Or we might find no one notices -- but deferring an MFC will help give
>> us a better sense of which outcome is more likely.
> 
> ... or maybe this doesn't matter before your later sysctl commit?
> 

Yes.  This change should not hurt anybody, because I change defaults for
vm.old_mlock and security.bsd.unprivileged_mlock for stable.

-- 
Andrey Zonov


[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQ0Z2gAAoJEBWLemxX/CvTgWAH/1BhjAiSlNbpy9+le2VB6n2j
wQqIlTsHGL/6WXDWIxYu2LYE+zMYHgPYE9JeD6Ok08VsE9JvfPNoCM8kL+QIrmtm
/AWL16/XnJkeuAVsJnxJd30xg96ebnv5pTnCi0uVj1k5K7eFLCAgzrOqK7Yde2Am
31/267mQcgZtVYDmkwfWcCtdXBKgzSg2BxXmCdtbeYuOaxrF9nAkV9+aO6W21Vdx
TV8Sufd+ZU+Q7KWCDMMRFsSSzFj0+KKrLrUiRgjUeQypRplz1GPnAyFdHkswG1CT
aya4HuvuMptuXMoEKZ05JKOILd6KxBrk1CPyUsLr3nJvfn/tXpXqPNei1tt8iVA=
=JR93
-----END PGP SIGNATURE-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50D19D9D.9090200>