On 06 Aug 2001 10:20:15 -0700, Linus Torvalds wrote:
> 2.4.x _does_ merge. Look for yourself. It doesn't merge mprotects, no. And
> why should glibc do mprotect() for a malloc() call? Electric Fence, yes.
> glibc, no.
What glibc does (when it decided to allocate in this way) is:
mmap(NULL,2*sz,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,-1,0)
free up 1*sz of space which isn't sz-aligned (presumably to prevent
fragmentation of its pools, now I think about it)
allocate out bits of the block mprotecting them as PROT_READ|PROT_WRITE
as it goes
Typically it's releasing multiples of 4kb at a time just like it brk()s
multiples of 4kb at a time. glibc doesn't catch accesses right down to
the byte but does catch accesses which are 'way off'. But really, yes,
you're right - if it's not catching everything it shouldn't catch
anything, since it's not its job. Unless the MAP_NORESERVE with
PROT_NONE is saving the system from even thinking about the unused parts
of the large slab glibc has just grabbed, in which case there is some
reason glibc should do things the way it does.
-- David Luyer Phone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:41 EST