Hugh Dickins wrote: > If the app can plan ahead as you're proposing, why doesn't it just > mmap the maximum it might need, mprotect PROT_NONE the end it doesn't > need yet, then progressively re-mprotect parts to make them accessible > as needed? Because the underlying file isn't larger than the initial mapping. In the one case I'm working on now the file can grow over time. More data is added at the end but the mapping cannot move in the address space. Using mmap with a too-large size for the underlying file and then hoping that future file growth is magically handled when those pages are accessed is not valid. > I'm missing what mremap gives you here that mprotect doesn't. Though > I do see that it would be nice not to be forced into mremap moving > all the time, because of other maps blocking you off: nice perhaps > to know what region of the layout is least likely to be so affected. Just accept here that moving is not an option. If remap cannot be used then a complete new mmap() with adjusted length is needed. That is unnecessarily expensive. It is the reason why there is mremap(). But mremap() with MREMAP_MAYMOVE is unreliable as it is implemented today. -- ➧ 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: Linus Torvalds <[email protected]>
- Re: mremap() use is racy
- References:
- mremap() use is racy
- From: Ulrich Drepper <[email protected]>
- Re: mremap() use is racy
- From: Hugh Dickins <[email protected]>
- mremap() use is racy
- Prev by Date: Re: [patch] suspend: update warnings
- Next by Date: Initramfs and TMPFS!
- Previous by thread: Re: mremap() use is racy
- Next by thread: Re: mremap() use is racy
- Index(es):