Re: mremap() use is racy

[Hugh Dickins <hugh@veritas.com>]

On Tue, 23 Aug 2005, Ulrich Drepper wrote:
> 
> 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?

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?

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.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/