qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [Bug 1054180] Re: DNS activity in slirp (user networking) m


From: Thomas Huth
Subject: [Qemu-devel] [Bug 1054180] Re: DNS activity in slirp (user networking) mode quickly depletes file descriptors and crashes qemu
Date: Mon, 21 Aug 2017 07:47:51 -0000

Triaging old bug tickets ... can you still reproduce this problem with
the latest version of QEMU (currently v2.9 or a release candidate of
2.10)?

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

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

Title:
  DNS activity in slirp (user networking) mode quickly depletes file
  descriptors and crashes qemu

Status in QEMU:
  Incomplete

Bug description:
  Hi, we have encountered quite some trouble with filedescriptor
  depletion of the qemu process. We have figured out that it can be
  demonstrated easily by doing a lot of DNS queries inside the VM -- in
  our real world scenario this is caused by running centos network
  install with a fast mirror.

  This situation is further problematic because qemu can't handle fd depletion 
very well:
  1) if ulimit is 1024 then qemu hangs in infinite loop whenever it tries to 
open the 1025th fd
  2) setting ulimit >1024 does not help that much because qemu uses select and 
max. fd set size is 1024 per default => qemu crashes because of buffer overflow 
in select()
  3) setting ulimit > 1024 AND recompiling with large enough fd set size AND 
disabling gcc's fortify source seems to work, but that's really just a hot-fix

  The problem can be replicated quite easily by running something like

  while :; do echo >/dev/udp/10.0.2.3/53; done

  inside a Linux VM -- crash comes very soon.

  This problem is present in current qemu (1.2.0) and in earlier as
  well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1054180/+subscriptions



reply via email to

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