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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |