[lkml]   [2005]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectmremap() use is racy
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 ❖

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-08-23 21:57    [W:0.034 / U:6.392 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site