Re: mremap() use is racy

[Ulrich Drepper]

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