[Qemu-devel] [Bug 682326] [NEW] linux-user/mmap exhaustion

[Brian Harring]

Public bug reported:

Currently when executing a linux-user target, mmap.c is in use- the
model it uses internally for figuring out what the mmap address actually
should be basically is an accumulator, every mmap invocation (regardless
of munmap's that cleared the previous usage) is center on the next page.

The end result of this is that it'll burn it's way through the space
soon enough, especially if it's a 64bit host w/ a 32bit target- the host
starts giving back 64bit addresses and the emulated mmap falls over
after failed attempts at a low MAP_FIXED range.

Where this becomes problematic is that glibc's FILE internals mmap a
*lot*- once per handle.  Any long running process can hit this wall-
rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so
it hits the wall surprisingly fast- at least on an opensuse 11.2 system
w/ mmap_min_addr of 65536 (their default), building qt reliably hits
that exhaustion during packaging.

Attached is basically, a hack- but one that works surprisingly well and
at least for meego building via qemu-arm, eliminates the failure
scenario I've described above.  It doesn't remove the exhaustion as much
as push it a fair bit back, although there are still a couple of ways to
trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only
remaining example I'm aware of).

This patch simply checks to see if upon an actual, host level munmap, if
the ending point of the munmap is where we'd allocate from next- if so,
it shifts the starting point back to the (now) unmap'd start, reusing
the space.  Rebuilding meego a couple of times over, thus far I've not
managed to flush out any failures that point at this specific patch,
so... it looks like it's doing the trick- that said the lack of a
g2h/h2g in the calculation still seems questionable to me.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
linux-user/mmap exhaustion
https://bugs.launchpad.net/bugs/682326
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: New

Bug description:
Currently when executing a linux-user target, mmap.c is in use- the model it 
uses internally for figuring out what the mmap address actually should be 
basically is an accumulator, every mmap invocation (regardless of munmap's that 
cleared the previous usage) is center on the next page.

The end result of this is that it'll burn it's way through the space soon 
enough, especially if it's a 64bit host w/ a 32bit target- the host starts 
giving back 64bit addresses and the emulated mmap falls over after failed 
attempts at a low MAP_FIXED range.

Where this becomes problematic is that glibc's FILE internals mmap a *lot*- 
once per handle.  Any long running process can hit this wall- rpmbuild 
unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall 
surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 
65536 (their default), building qt reliably hits that exhaustion during 
packaging.

Attached is basically, a hack- but one that works surprisingly well and at 
least for meego building via qemu-arm, eliminates the failure scenario I've 
described above.  It doesn't remove the exhaustion as much as push it a fair 
bit back, although there are still a couple of ways to trigger it 
(http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm 
aware of).

This patch simply checks to see if upon an actual, host level munmap, if the 
ending point of the munmap is where we'd allocate from next- if so, it shifts 
the starting point back to the (now) unmap'd start, reusing the space.  
Rebuilding meego a couple of times over, thus far I've not managed to flush out 
any failures that point at this specific patch, so... it looks like it's doing 
the trick- that said the lack of a g2h/h2g in the calculation still seems 
questionable to me.