[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Launchpad Bug Tracker
Subject: [Qemu-devel] [Bug 682326] Re: linux-user/mmap exhaustion
Date: Sat, 18 Feb 2017 04:17:27 -0000

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
       Status: Incomplete => Expired

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  linux-user/mmap exhaustion

Status in QEMU:

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.

To manage notifications about this bug go to:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]