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:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: mremap() use is racy
- From: Hugh Dickins <[email protected]>
- Re: mremap() use is racy
- Prev by Date: Re: select() efficiency / epoll
- Next by Date: [-mm PATCH] drivers/char/speakup/synthlist.h - Fix warnings with -Wundef
- Previous by thread: Re: SCSI tape problems: 2.6.12, DLT 7000, Adaptec AIC7xxx
- Next by thread: Re: mremap() use is racy
- Index(es):