From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 00:31:57 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 394C516A418; Fri, 4 Jan 2008 00:31:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C93D13C459; Fri, 4 Jan 2008 00:31:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C4F9947BDB; Thu, 3 Jan 2008 19:31:56 -0500 (EST) Date: Fri, 4 Jan 2008 00:31:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: Message-ID: <20080104002715.N30578@fledge.watson.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org> <200801031746.15225.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Jason Evans Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 00:31:57 -0000 On Thu, 3 Jan 2008, Scott Long wrote: >>> That is a pretty damning argument in my mind. Why make such a major >>> change right before the release when it's effectively useless? >> >> The motivation for the change is to preserve POLA as malloc() does honor >> RLIMIT_DATA in previous releases (4.x, 6.x, etc.). That said, I think >> RLIMIT_VMEM is probably more useful going forward. I know at work we have >> lots of hacks to deal with maxdsiz and trying to allow apps that use large >> malloc() and large mmap both cooperate. Having one resource limit for >> malloc + mmap is probably best for the future. The reason I'm more of a fan of introducing LIMIT_SWAP is that I'd like to be able to specifically avoid swap exhaustion by a process without preventing it from memory mapping large files. > If it were happening on a stable branch, I'd agree more with the POLA > argument. The tradeoff between last minute destabilization, which is exactly > what happened here, and the highly imperfect and antiquated justification, > is pretty bogus. When Alan proposed this as the approach, it was presumably under the assumption that it would be non-disruptive. As it has proven highly disruptive, it's obviously not getting MFC'd for the release. Instead we'll have to work on a solution for after .0, but make sure to document that the default swap resource limits effectively enforced in all prior FreeBSD releases are *not* enforced on 7.0, and that administrators wanting to prevent users from exhausting swap accidentally with something like the following: int main(int argc, char *argv[]) { char *c; while (1) { c = malloc(getpagsize()); if (c == NULL) err(-1, "malloc"); *c = 'a'; } } will need to now manually set the virtual memory limit in login.conf. Note that the above strongly resembles frequently run CGI scripts written by many naive CGI script authors, so is something that we'd like to be robust against in the same way we prefer to be robust against: int main(int argc, char *argv[]) { while (1) { fork(); } } Smacking the user is obviously a good idea, but taking down the multi-user web server is not. Robert N M Watson Computer Laboratory University of Cambridge