1. 03 12月, 2009 3 次提交
  2. 28 11月, 2009 1 次提交
  3. 21 11月, 2009 1 次提交
  4. 19 11月, 2009 1 次提交
  5. 18 11月, 2009 1 次提交
  6. 17 11月, 2009 2 次提交
  7. 11 11月, 2009 1 次提交
    • M
      net: disable draining tap queue in one go · 3e01c7b9
      Mark McLoughlin 提交于
      If qemu_send_packet_async() returns zero, it means the packet has been
      queued and the sent callback will be invoked once it has been flushed.
      
      This is only possible where the NIC's receive() handler returns zero
      and promises to notify the networking core that room is available in its
      queue again.
      
      In the case where the receive handler does not have this capability
      (and its queue fills up) it returns -1 and the networking core does not
      queue up the packet. This condition is indicated by a -1 return from
      qemu_send_packet_async().
      
      Currently, tap handles this condition simply by dropping the packet. It
      should do its best to avoid getting into this situation by checking such
      NIC's have room for a packet before copying the packet from the tap
      interface.
      
      tap_send() used to achieve this by only reading a single packet before
      returning to the mainloop. That way, tap_can_send() is called before
      reading each packet.
      
      tap_send() was changed to completely drain the tap interface queue
      without taking into account the situation where the NIC returns an
      error and the packet is not queued. Let's start fixing this by
      reverting to the previous behaviour of reading one packet at a time.
      Reported-by: NScott Tsai <scottt.tw@gmail.com>
      Tested-by: NSven Rudolph <Sven_Rudolph@drewag.de>
      Signed-off-by: NMark McLoughlin <markmc@redhat.com>
      Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
      3e01c7b9
  8. 12 10月, 2009 3 次提交
  9. 04 10月, 2009 1 次提交
    • J
      usb-linux.c: fix buffer overflow · babd03fd
      Jim Paris 提交于
      In usb-linux.c:usb_host_handle_control, we pass a 1024-byte buffer and
      length to the kernel.  However, the length was provided by the caller
      of dev->handle_packet, and is not checked, so the kernel might provide
      too much data and overflow our buffer.
      
      For example, hw/usb-uhci.c could set the length to 2047.
      hw/usb-ohci.c looks like it might go up to 4096 or 8192.
      
      This causes a qemu crash, as reported here:
        http://www.mail-archive.com/kvm@vger.kernel.org/msg18447.html
      
      This patch increases the usb-linux.c buffer size to 2048 to fix the
      specific device reported, and adds a check to avoid the overflow in
      any case.
      Signed-off-by: NJim Paris <jim@jtan.com>
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      babd03fd
  10. 25 9月, 2009 1 次提交
  11. 24 9月, 2009 1 次提交
  12. 23 9月, 2009 5 次提交
  13. 18 9月, 2009 1 次提交
  14. 17 9月, 2009 2 次提交
  15. 16 9月, 2009 1 次提交
  16. 15 9月, 2009 2 次提交
  17. 29 8月, 2009 1 次提交
  18. 28 8月, 2009 12 次提交