Re: libio/libioP.h:ALLOC_BUF() unconditionally uses mmap()

[Wolfram Gloger]

Hi,

> I have been having a problem on ia32 Linux with a program (MAGMA) linked
> against glibc that eschews malloc() and does its own memory allocation
> with sbrk().

Ugh, is that absolutely necessary?  You really need 3GB _contiguous_
memory?

> I brought this issue up on the Linux Kernel Mailing List, and it was 
> suggested that this was due to a misbehavior by glibc.  Specifically:
> 
> On 13 Dec 01, Petr Vandrovec <address@hidden> wrote:
> 
> > [The mapping comes from] code in glibc-2.2.4/libio/libioP.h:ALLOC_BUF(), 
> > which unconditionally does 'mmap(0, ROUND_TO_PAGE(size),
> > PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)' instead of
> > 'malloc(size)' when it finds that underlying system supports malloc.
> 
> So I wanted to ask if this use of mmap() could be changed to a use of
> malloc() without any ill effects?

There definitely was a _good_ reason for this allocation of I/O
buffers, this was changed in 1995 or so.  IIRC, mmap() was used
precisely to make it possible for user applications to override malloc
and friends.  This is because eg. the buffer for stdin can be
allocated very early, even before main() has started.  If 'malloc' was
used, the hook pointers for overriding might still point to the system
allocations, and then later the user-defined routine for free() might
be used on the I/O buffer with disastrous consequences.

mmap also has the advantage that it's thread-safe, and the chunk is
nicely page-aligned without fragmentation.  There may have been other
reasons which I don't remember right now.

I'd suggest that you reconfigure the kernel to map at something like
0xA0000000 or something.  I believe there are patches around to make
this runtime-configurable via a /proc setting.

Regards,
Wolfram.