Date: Thu, 3 Jan 2008 16:08:59 -0700 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@freebsd.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-current@freebsd.org, Jason Evans <jasone@freebsd.org> Subject: Re: sbrk(2) broken Message-ID: <FEF3789C-90F1-4EBD-A744-D84BDE52E792@samsco.org> In-Reply-To: <200801031746.15225.jhb@freebsd.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <477D6078.5030805@samsco.org> <200801031746.15225.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 3, 2008, at 3:46 PM, John Baldwin wrote: > On Thursday 03 January 2008 05:23:52 pm Scott Long wrote: >> Dag-Erling Sm=F8rgrav wrote: >>> Jason Evans <jasone@freebsd.org> writes: >>>> [sbrk is broken] >>> >>> The real question is why we would revert perfectly good code =20 >>> (jemalloc) >>> from using a modern interface to using one that has been obsolete =20= >>> for >>> twenty years, and marked as such in the man page for seven years. >>> >>> If rwatson@ wants malloc() to respect resource limits, he can bloody >>> well fix mmap(). Until he does, the datasize limit is a joke =20 >>> anyway, as >>> anyone can circumvent it by either using mmap() instead of =20 >>> malloc() or >>> setting _malloc_options before calling malloc(). >>> >> >> 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 =20 > 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 =20 > we have > lots of hacks to deal with maxdsiz and trying to allow apps that use =20= > large > malloc() and large mmap both cooperate. Having one resource limit =20 > for malloc > + mmap is probably best for the future. > If it were happening on a stable branch, I'd agree more with the POLA =20= argument. The tradeoff between last minute destabilization, which is exactly =20 what happened here, and the highly imperfect and antiquated justification, is pretty =20= bogus. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FEF3789C-90F1-4EBD-A744-D84BDE52E792>