Date: Wed, 19 Dec 2012 11:04:01 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Andrey Zonov <zont@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: <DF880685-1BB1-4D35-AC53-D77657842FC2@FreeBSD.org> In-Reply-To: <50D19D9D.9090200@FreeBSD.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> <50D19D9D.9090200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Dec 2012, at 10:57, Andrey Zonov wrote: >>> 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. >>>=20 >>> Or we might find no one notices -- but deferring an MFC will help = give >>> us a better sense of which outcome is more likely. >>=20 >> ... or maybe this doesn't matter before your later sysctl commit? >=20 > Yes. This change should not hurt anybody, because I change defaults = for > vm.old_mlock and security.bsd.unprivileged_mlock for stable. Very exciting indeed, then! Lots of gpg/etc users will appreciate this = greatly. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DF880685-1BB1-4D35-AC53-D77657842FC2>