malloc(3) ignores RLIMIT_DATA

[Kostik Belousov]

On Tue, Feb 19, 2008 at 06:58:08PM +0000, Robert Watson wrote:
> 
> 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.

Yes, per-process limits can be added too, although it would require some
additional thinking. The persistent objects backed by anonymous memory,
like SysV shm or shm_open(2) handles would be billed for the creator
only. It is not immediately obvious whether it is right or not.

Anyway, I want to get the review first, before doing further
modifications.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080219/e1f93cb2/attachment.pgp