This is the mail archive of the
mailing list for the glibc project.
malloc using mprotect
- To: libc-alpha at sources dot redhat dot com, Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Subject: malloc using mprotect
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 9 Aug 2001 12:00:50 -0400
- References: <20010806070124.J3862@devserv.devel.redhat.com> <Pine.LNX.firstname.lastname@example.org>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Mon, Aug 06, 2001 at 10:17:02AM -0700, Linus Torvalds wrote:
> On Mon, 6 Aug 2001, Jakub Jelinek wrote:
> > Even worse, it means people not using -ac kernels cannot malloc a lot of
> > memory but by recompiling the kernel.
> Hey guys. Let's calm down a bit, and look at the problem.
> Why the hell is glibc doing something so stupid in the first place? Yes,
> we can work around it, but it sounds like the glibc apporoach is slow and
> stupid even if we _did_ work around it. Mind explaining what the logic of
> "fixing" the kernel is?
What's the exact reason for using mmap(..., PROT_NONE, ...) first and then
mprotect (..., PROT_READ|PROT_WRITE) chunk by chunk instead of
mmap(..., PROT_READ|PROT_WRITE, ...) first and nothing afterwards?
Is it primarily to catch bogus programs? If yes, wouldn't it be better to
conditionalize this on MALLOC_CHECK_ ? But then it would be probably good
idea to mprotect(..., PROT_NONE) after all allocations in certain region go
Or is it primarily so that the whole heap does not count immediately into
rlimits, but slowly as malloc areas are requested?
If we explain it to Linus, I guess he could accept mprotect(2) patches to do
some merging in the common case.