On Thu, 3 Jan 2008, Scott Long wrote:

quoted text
>>> 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.

quoted text
> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"