Date: Tue, 19 Feb 2008 18:58:08 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Jason Evans <jasone@freebsd.org> Cc: Igor Sysoev <is@rambler-co.ru>, freebsd-current@FreeBSD.ORG Subject: Re: malloc(3) ignores RLIMIT_DATA Message-ID: <20080219185615.R21494@fledge.watson.org> In-Reply-To: <47BB0D29.5080403@freebsd.org> References: <20080219151809.GF57366@rambler-co.ru> <47BB0D29.5080403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Feb 2008, Jason Evans wrote: >> As sbrk() is less preferable because of framentation and race conditions, >> why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it >> in malloc(3) ? > > There has been general agreement among the people I've discussed this issue > with that the correct solution is to add a separate resource limit for > anonymously mapped memory, which would provide capabilities similar to what > your suggestion would provide. Konstantine has updated his patches and reported on them in the recent status report: http://www.freebsd.org/news/status/report-2007-10-2007-12.html#VM-Overcommit Here's the main site for information on the patch: http://people.freebsd.org/~kib/overcommit/ He describes a per-uid limit, but I think it might also be useful to have a per-process limit tht can also be enforced, although possibly not by default, so that protecting applications from each other doesn't require creating separate users for them. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080219185615.R21494>