[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.020 / U:8.368 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site