Message ID | 1330813157-11793-1-git-send-email-agraf@suse.de |
---|---|
State | New |
Headers | show |
> When mmap()'ing memory somewhere where it's not allowed, we should not > default to the "next free page" which could be right after brk()'ed memory, > but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its > space later on. NACK, As discussed on IRC. Effectively prevents mmap from allocating below TARGET_UNMAPPED_BASE. This wastes a lot of perfectly good address space. With small -R values it leaves mmap with no usable virtual address space. Paul
diff --git a/linux-user/mmap.c b/linux-user/mmap.c index e4db455..4219b16 100644 --- a/linux-user/mmap.c +++ b/linux-user/mmap.c @@ -244,7 +244,13 @@ static abi_ulong mmap_find_vma_reserved(abi_ulong start, abi_ulong size) } prot = page_get_flags(addr); if (prot) { - last_addr = addr + qemu_host_page_size; + if (addr < mmap_next_start) { + /* Someone randomly shot into potential brk space, + better remap higher up when already remapping */ + last_addr = TASK_UNMAPPED_BASE; + } else { + last_addr = addr + qemu_host_page_size; + } } } mmap_next_start = addr;
When mmap()'ing memory somewhere where it's not allowed, we should not default to the "next free page" which could be right after brk()'ed memory, but rather at TARGET_UNMAPPED_BASE, which ensures that brk() can extend its space later on. Reported-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- linux-user/mmap.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-)