mremap() use is racy

[Ulrich Drepper <drepper@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Not the mremap() implementation itself, so don't worry.

If mremap() is to be used without the MREMAP_MAYMOVE flag the call will
only succeed of the address space after the block which is to be
remapped is empty.  This is rarely the case since there are many users
of mmap and memory is allocated consecutively in many cases.

So what programs have to do is to make sure ahead of time that the
mremap() call can succeed.  The best way to do this is using an
anonymous, unused, unusable mapping.  Code like this:

p = mmap(NULL, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANON, -1, 0);

mmap(p, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);


Then when the mapping has to be extended one should be able to use mremap():


mremap(p, 16384, 32768, 0);


But this is not possible since mremap() respects the anonymous mapping.
 So one has to use


munmap((char*)p + 16384, 16384);


before the mremap() call.  But this is where the race comes in.  Some
other thread might allocate these blocks before the mremap() call can do it.


One possible solution would be to add a flag to mremap() which allows
mremap() to steal memory.  In general that would be too dangerous but we
could limit it to private, anonymous mappings which have no access
permissions (i.e., PROT_NONE with MAP_PRIVATE and MAP_ANON).  One
explicitly has to allocate such blocks, they don't appear naturally.
And the program in any case knows about the address space layout.

So, how about adding MREMAP_MAPOVERNONE or so?

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]