diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/78 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/780 | 69 | ||||
| -rw-r--r-- | results/classifier/108/other/781 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/782 | 20 | ||||
| -rw-r--r-- | results/classifier/108/other/783 | 18 | ||||
| -rw-r--r-- | results/classifier/108/other/785 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/785668 | 422 | ||||
| -rw-r--r-- | results/classifier/108/other/786 | 32 | ||||
| -rw-r--r-- | results/classifier/108/other/786208 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/786209 | 30 | ||||
| -rw-r--r-- | results/classifier/108/other/786440 | 42 | ||||
| -rw-r--r-- | results/classifier/108/other/786442 | 25 | ||||
| -rw-r--r-- | results/classifier/108/other/787 | 27 | ||||
| -rw-r--r-- | results/classifier/108/other/788701 | 31 | ||||
| -rw-r--r-- | results/classifier/108/other/788881 | 34 | ||||
| -rw-r--r-- | results/classifier/108/other/788886 | 28 |
16 files changed, 856 insertions, 0 deletions
diff --git a/results/classifier/108/other/78 b/results/classifier/108/other/78 new file mode 100644 index 000000000..1965c2675 --- /dev/null +++ b/results/classifier/108/other/78 @@ -0,0 +1,16 @@ +performance: 0.805 +device: 0.783 +network: 0.712 +debug: 0.587 +PID: 0.393 +boot: 0.383 +graphic: 0.381 +semantic: 0.258 +files: 0.214 +other: 0.191 +permissions: 0.183 +socket: 0.118 +vnc: 0.111 +KVM: 0.085 + +msmouse serial mouse emulation broken? No id byte sent on reset diff --git a/results/classifier/108/other/780 b/results/classifier/108/other/780 new file mode 100644 index 000000000..e28d9e815 --- /dev/null +++ b/results/classifier/108/other/780 @@ -0,0 +1,69 @@ +other: 0.811 +graphic: 0.710 +KVM: 0.704 +permissions: 0.701 +performance: 0.697 +vnc: 0.683 +debug: 0.647 +device: 0.644 +files: 0.611 +semantic: 0.595 +socket: 0.581 +network: 0.557 +boot: 0.550 +PID: 0.543 + +qemu-system-x86_64: qemu dead-lock when mirror job exit and vm stop in a race +Description of problem: +machine under continuous pressure, at the end of the migration phase. +Libvirtd construction exception at the same time. +In mirror_run, mirror_write_complete set s->ret to negative value and exit mirror_run; Job_co_entry throws the bh of job_exit into the main thread; + +While the live_migration thread gets the qemu_global_mutex, and set to main thread by blk_set_aio_context; when it just polles the bh of job_exit, and run to bdrv_flush. So there need the main thread to process bdrv_flush_co_entry, then we can exit bdrv_flush. +If the main thread is waiting the qemu_mutex_lock_iothread_impl, bdrv_flush_co_entry cannot be executed, and the Live_migration thread cannot exit to release qemu_global_mutex, resulting in deadlock +Steps to reproduce: +1.migrate the machine and let machine under continuous pressure; +2.gdb to qemu and make break point to virtio_blk_data_plane_stop; +3.when hit virtio_blk_data_plane_stop, kill libvirtd; +4.let live_migration thread to poll job_exit +Additional information: +``` +#0 0x00007f8f662d12f2 in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:112 +#1 0x00007f8f662d58ae in aio_poll (ctx=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#2 0x00007f8f6530bcca in bdrv_flush (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block/io.c:2778 +#3 0x00007f8f65345143 in bdrv_close (bs=bs@entry=0x5580c5857b30) at /usr/src/qemu/block.c:4073 +#4 0x00007f8f65345373 in bdrv_delete (bs=0x5580c5857b30) at /usr/src/qemu/block.c:4335 +#5 0x00007f8f65345405 in bdrv_unref (bs=<optimized out>) at /usr/src/qemu/block.c:5676 +#6 0x00007f8f65344d95 in bdrv_root_unref_child (child=<optimized out>) at /usr/src/qemu/block.c:2516 +#7 0x00007f8f65353f56 in block_job_remove_all_bdrv (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/blockjob.c:203 +#8 0x00007f8f65317b87 in mirror_exit_common (job=0x5580c6d55cc0) at /usr/src/qemu/block/mirror.c:776 +#9 0x00007f8f65317cc8 in mirror_abort (job=<optimized out>) at /usr/src/qemu/block/mirror.c:804 +#10 0x00007f8f6632737b in job_finalize_single (job=job@entry=0x5580c6d55cc0) at /usr/src/qemu/job.c:680 +#11 0x00007f8f66327d70 in job_completed_txn_abort (job=<optimized out>) at /usr/src/qemu/job.c:758 +#12 0x00007f8f66328018 in job_exit (opaque=0x5580c6d55cc0) at /usr/src/qemu/job.c:873 +#13 0x00007f8f662d130f in aio_bh_poll (ctx=ctx@entry=0x5580c53a5c60) at /usr/src/qemu/util/async.c:118 +#14 0x00007f8f662d5716 in aio_poll (ctx=ctx@entry=0x5580c53a5c60, blocking=blocking@entry=true) at /usr/src/qemu/util/aio-posix.c:736 +#15 0x00007f8f662e6b4d in aio_wait_bh_oneshot (ctx=0x5580c53a5c60, cb=<optimized out>, opaque=<optimized out>) at /usr/src/qemu/util/aio-wait.c:71 +#16 0x00007f8f65340978 in bdrv_attach_aio_context (bs=bs@entry=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60) at /usr/src/qemu/block.c:5985 +#17 0x00007f8f65345fd5 in bdrv_set_aio_context_ignore (bs=0x5580c5a07ef0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6050 +#18 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=0x5580c5857b30, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#19 0x00007f8f65353bd4 in child_job_set_aio_ctx (c=<optimized out>, ctx=0x5580c53a5c60, ignore=0x7f8eb8ff8c20) at /usr/src/qemu/blockjob.c:172 +#20 0x00007f8f6534604b in bdrv_set_aio_context_ignore (bs=0x5580c53c46c0, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6040 +#21 0x00007f8f6534609e in bdrv_set_aio_context_ignore (bs=bs@entry=0x5580c5978290, new_context=new_context@entry=0x5580c53a5c60, ignore=ignore@entry=0x7f8eb8ff8c20) at /usr/src/qemu/block.c:6032 +#22 0x00007f8f653462b8 in bdrv_child_try_set_aio_context (bs=bs@entry=0x5580c5978290, ctx=ctx@entry=0x5580c53a5c60, ignore_child=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block.c:6145 +#23 0x00007f8f653029aa in blk_do_set_aio_context (blk=0x5580c53c42b0, new_context=0x5580c53a5c60, update_root_node=update_root_node@entry=true, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1948 +#24 0x00007f8f65304b0d in blk_set_aio_context (blk=<optimized out>, new_context=<optimized out>, errp=errp@entry=0x0) at /usr/src/qemu/block/block-backend.c:1980 +#25 0x00007f8f64f07976 in virtio_blk_data_plane_stop (vdev=0x5580c6d8a510) at /usr/src/qemu/hw/block/dataplane/virtio-blk.c:305 +#26 0x00007f8f64f7be83 in virtio_bus_stop_ioeventfd (bus=0x5580c6d8a498) at /usr/src/qemu/hw/virtio/virtio-bus.c:247 +#27 0x00007f8f64f77e8b in virtio_vmstate_change (opaque=0x5580c6d8a510, running=0, state=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/hw/virtio/virtio.c:2423 +#28 0x00007f8f663563f5 in vm_state_notify (running=running@entry=0, state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/huawei/microvm/microvm-platform.c:196 +#29 0x00007f8f66335af9 in do_vm_stop (state=RUN_STATE_FINISH_MIGRATE, send_stop=send_stop@entry=true) at /usr/src/qemu/cpus.c:1130 +#30 0x00007f8f66335dd1 in vm_stop (state=<optimized out>) at /usr/src/qemu/cpus.c:2207 +#31 0x00007f8f66335f7e in vm_stop_force_state (state=state@entry=RUN_STATE_FINISH_MIGRATE) at /usr/src/qemu/cpus.c:2267 +#32 0x00007f8f65197cfc in migration_try_vm_stop_and_save_concurrent (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:2976 +#33 0x00007f8f6519c627 in migration_completion (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3039 +#34 0x00007f8f6519cc8b in migration_iteration_run (s=s@entry=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3571 +#35 0x00007f8f6519d190 in migration_thread (opaque=0x5580c609a010) at /usr/src/qemu/migration/migration.c:3801 +#36 0x00007f8f662d82e0 in qemu_thread_start (args=0x5580c57d0300) at /usr/src/qemu/util/qemu-thread-posix.c:519 +#37 0x00007f8f6648bf3b in start_thread (arg=0x7f8eb8ff9700) at pthread_create.c:486 +``` diff --git a/results/classifier/108/other/781 b/results/classifier/108/other/781 new file mode 100644 index 000000000..b4c5b7c6d --- /dev/null +++ b/results/classifier/108/other/781 @@ -0,0 +1,16 @@ +performance: 0.885 +debug: 0.696 +network: 0.621 +device: 0.525 +graphic: 0.398 +semantic: 0.346 +KVM: 0.224 +boot: 0.214 +socket: 0.156 +vnc: 0.140 +PID: 0.062 +other: 0.028 +permissions: 0.025 +files: 0.017 + +Assertion `addr < cache->len && 2 <= cache->len - addr' failed in address_space_stw_le_cached diff --git a/results/classifier/108/other/782 b/results/classifier/108/other/782 new file mode 100644 index 000000000..f9eccc551 --- /dev/null +++ b/results/classifier/108/other/782 @@ -0,0 +1,20 @@ +device: 0.858 +vnc: 0.750 +network: 0.682 +graphic: 0.585 +semantic: 0.454 +files: 0.398 +other: 0.374 +PID: 0.351 +socket: 0.328 +boot: 0.304 +permissions: 0.144 +debug: 0.121 +performance: 0.087 +KVM: 0.076 + +nvme: DMA reentrancy issue leads to use-after-free (CVE-2021-3929) +Description of problem: +A DMA reentrancy issue was found in the NVM Express Controller (NVMe) emulation. Functions dma_buf_write() or dma_buf_read() in hw/nvme/ctrl.c:nvme_tx() can be called without checking if the destination region overlaps with device's MMIO. This is similar to CVE-2021-3750 (https://gitlab.com/qemu-project/qemu/-/issues/541) and, just like it, when the reentrancy write triggers the reset function nvme_ctrl_reset(), data structs will be freed leading to a use-after-free issue. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition or, potentially, executing arbitrary code within the context of the QEMU process on the host. + +This issue was reported by Qiuhao Li. diff --git a/results/classifier/108/other/783 b/results/classifier/108/other/783 new file mode 100644 index 000000000..0154b633f --- /dev/null +++ b/results/classifier/108/other/783 @@ -0,0 +1,18 @@ +performance: 0.769 +device: 0.767 +graphic: 0.370 +semantic: 0.368 +other: 0.223 +boot: 0.173 +debug: 0.164 +permissions: 0.153 +network: 0.121 +vnc: 0.109 +KVM: 0.061 +files: 0.038 +PID: 0.033 +socket: 0.025 + +risc-v: provide CPU without MMU +Additional information: + diff --git a/results/classifier/108/other/785 b/results/classifier/108/other/785 new file mode 100644 index 000000000..c4a873fb2 --- /dev/null +++ b/results/classifier/108/other/785 @@ -0,0 +1,16 @@ +device: 0.862 +graphic: 0.608 +performance: 0.411 +semantic: 0.335 +debug: 0.331 +PID: 0.204 +permissions: 0.184 +files: 0.111 +network: 0.093 +vnc: 0.090 +other: 0.053 +boot: 0.028 +socket: 0.008 +KVM: 0.003 + +Build failure on macOS with jack diff --git a/results/classifier/108/other/785668 b/results/classifier/108/other/785668 new file mode 100644 index 000000000..5c8a86e1b --- /dev/null +++ b/results/classifier/108/other/785668 @@ -0,0 +1,422 @@ +permissions: 0.897 +KVM: 0.892 +performance: 0.839 +graphic: 0.811 +PID: 0.810 +device: 0.791 +other: 0.789 +network: 0.774 +debug: 0.757 +vnc: 0.719 +semantic: 0.692 +boot: 0.687 +files: 0.661 +socket: 0.649 + +bonding inside a bridge does not update ARP correctly when bridged net accessed from within a VM + +Binary package hint: qemu-kvm + +Description: Ubuntu 10.4.2 +Release: 10.04 + + +When setting a KVM host with a bond0 interface made of eth0 and eth1 and using this bond0 interface for a bridge to KVM VMs, the ARP tables do not get updated correctly and + +Reproducible: 100%, with any of the load balancing mode + +How to reproduce the problem + +- Prerequisites: +1 One KVM system with 10.04.02 server, configured as a virtual host is needed. The following /etc/network/interfaces was used for the test : + +# grep -v ^# /etc/network/interfaces +auto lo +iface lo inet loopback + + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode balance-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 + bridge-stp off + bridge-fd 9 + bridge-hello 2 + bridge-maxage 12 + bridge_max_wait 0 + +One VM running Maverick 10.10 server, standard installation, using the following /etc/network/interfaces file : + +grep -v ^# /etc/network/interfaces + +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet static + address 10.153.107.92 + netmask 255.255.255.0 + network 10.153.107.0 + broadcast 10.153.107.255 + +-------------- +On a remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +On VM +$ arp -an +? (10.153.107.61) at <incomplete> on eth0 + +1) Test #1 : ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : + +- On remote bridged network system : +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +From 10.153.107.92 icmp_seq=1 Destination Host Unreachable +From 10.153.107.92 icmp_seq=2 Destination Host Unreachable +From 10.153.107.92 icmp_seq=3 Destination Host Unreachable +^C +--- 10.153.107.80 ping statistics --- +4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3010ms +pipe 3 +ubuntu@vm1:~$ arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at <incomplete> on eth0 + +2) Test #2 : ping from remote bridged network system (10.153.107.80) to VM (10.153.107.92) : + +- On remote bridged network system : +$ ping 10.153.107.92 +PING 10.153.107.92 (10.153.107.92) 56(84) bytes of data. +64 bytes from 10.153.107.92: icmp_req=1 ttl=64 time=327 ms +64 bytes from 10.153.107.92: icmp_req=2 ttl=64 time=158 ms +64 bytes from 10.153.107.92: icmp_req=3 ttl=64 time=157 ms +^C +--- 10.153.107.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 157.289/214.500/327.396/79.831 ms +caribou@marvin:~$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +arp -an +? (10.153.107.61) at <incomplete> on eth0 +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on eth0 + + +3) Test #3 : New ping from VM (10.153.107.92) to remote bridged network system (10.153.107.80) : +- On remote bridged network system : +$ arp -an +? (10.153.107.188) à 00:1c:c4:6a:c0:dc [ether] sur tap0 +? (16.1.1.1) à 00:17:33:e9:ee:3c [ether] sur wlan0 +? (10.153.107.52) à 00:1c:c4:6a:c0:de [ether] sur tap0 +? (10.153.107.92) à 52:54:00:8c:e0:3c [ether] sur tap0 + +- On KVMhost +ubuntu@VMhost:~$ arp -an +? (10.153.107.80) at ee:99:73:68:f0:a5 [ether] on br0 + +- On VM +ubuntu@vm1:~$ ping 10.153.107.80 +PING 10.153.107.80 (10.153.107.80) 56(84) bytes of data. +64 bytes from 10.153.107.80: icmp_req=1 ttl=64 time=154 ms +64 bytes from 10.153.107.80: icmp_req=2 ttl=64 time=170 ms +64 bytes from 10.153.107.80: icmp_req=3 ttl=64 time=154 ms +^C +--- 10.153.107.80 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2003ms +rtt min/avg/max/mdev = 154.072/159.465/170.058/7.504 ms + +tcpdump traces are available for those tests. Test system is available upon request. + +Workaround: + +Use the bonded device in "active-backup" mode + +ProblemType: Bug +DistroRelease: Ubuntu 10.04.02 +Package: qemu-kvm-0.12.3+noroms-0ubuntu9.6 +Uname: Linux 2.6.35-25-serverr x86_64 +Architecture: amd64 + +Thanks for reporting this bug and the detailed reproduction instructions. I would mark it high, but since you offer a workaround I'll mark it medium instead. + +What does your /etc/modprobe.d/bonding show? + +I've not used this combination myself, but from those who have, a few things do appear fragile, namely: + +1. if you are using 802.3ad, you need trunking enabled on the physical switch + +2. some people find that turning stp on helps (http://www.linuxquestions.org/questions/linux-networking-3/bridging-a-bond-802-3ad-only-works-when-stp-is-enabled-741640/) + +But I'm actually wondering whether this patch: + +http://permalink.gmane.org/gmane.linux.network/159403 + +may be needed. If so, then even the natty kernel does not yet have that fix. + +I am marking this as affecting the kernel, since I believe that is where the bug lies. + + +Actually, I may be wrong about this being a kernel issue. + +Are you always able to ping the remote host from the kvm host, even when you can't do so from the VM? + +In addition to kvmhost's /etc/modprove.d/bonding.conf, can you also please provide the configuration info for the KVM vm? (If a libvirt host, then the network-related (or just all) xml info, or else the 'ps -ef | grep kvm' output). Also the network configuration insid the KVM VM. In particular, if the KVM VM has a bridge, that one would need to have stp turned on, but I doubt you have that. + +Yup, I can reproduce this 100%. + +I'm setting up networking as described above, and then starting virtual machines with: + +sudo tunctl -u 1000 -g 1000 -t tap0 +sudo /sbin/ifconfig $1 0.0.0.0 up +sudo brctl addif br0 tap0 + +kvm -drive file=disk.img,if=virtio,cache=none,boot=on -m 1024 -vnc :1 -net nic,model=virtio -net tap,script=no,ifname=tap0,downscript=no + +With mode=balance-rr, I can't run dhclient from the guest. With either +bond0 as active-backup, or without bond0 (with eth0 directly in br0), +I can. + + +Following the advice toward the bottom of + +http://forum.proxmox.com/archive/index.php/t-2676.html?s=e8a9cfc9a128659e4a61efec0b758d3e + +I was able to get this to work with balance-rr by changing a few bridge properties. The following was my /etc/network/interfaces: + +# This file describes the network interfaces available on your system +# and how to activate them. For more information, see interfaces(5). + +# The loopback network interface +auto lo +iface lo inet loopback + +auto bond0 +iface bond0 inet manual + post-up ifconfig $IFACE up + pre-down ifconfig $IFACE down + bond-slaves none + bond_mode active-rr + bond-downdelay 250 + bond-updelay 120 +auto eth0 +allow-bond0 eth0 +iface eth0 inet manual + bond-master bond0 +auto eth1 +allow-bond0 eth1 +iface eth1 inet manual + bond-master bond0 + +auto br0 +iface br0 inet dhcp + # dns-* options are implemented by the resolvconf package, if installed + bridge-ports bond0 +# bridge-stp off +# bridge-fd 9 +# bridge-hello 2 +# bridge-maxage 12 +# bridge_max_wait 0 + bridge_stp on + bridge_maxwait 0 + bridge_maxage 0 + bridge_fd 0 + bridge_ageing 0 + +I don't know if this is acceptable to you since stp is on. If not, is using balance-alb (which did also work for me) acceptable? + +Following your suggestions, I modified my /etc/network/interfaces & added the STP options to my test environment. Following that, I am now able to ping to the remote system using the following bonding modes : + +* 802.3ad (4) +* tlb (5) +* alb (6) + +For unknown reasons, I'm still unable to use balance-rr unlike your setup. But that might not be much of an issue as those modes listed above might be sufficient. I must go & check that. And now, the two VMs are able to ping each other. + +One thing regarding your listed /etc/network/interfaces : I think that there is a typo as 'bond_mode active-rr' is not a support bonding mode. + +Regarding your request for /etc/modprove.d/bonding.conf, there is no such file on my test system. Let me know if you still require the xml dump of the VM. + +Quoting Louis Bouchard (<email address hidden>): +> Regarding your request for /etc/modprove.d/bonding.conf, there is no +> such file on my test system. + +Right, sorry, that's obsolete as of hardy, sorry. + +> Let me know if you still require the xml +> dump of the VM. + +Thanks, no, as I'm able to reproduce that won't be necessary. + + +I can reproduce this just using lxc, which simply attaches an endpoint of a veth tunnel to the bridge. With balance-rr mode, i can't dhcp in the guest. With balance-alb, I can. + +That means this is not actually qemu-kvm, but a bug in the kernel or (unlikely) ifenslave. + +My next steps will be to test on maverick and natty, look through linux-2.6/drivers/net/bonding and linux-2.6/net/bridge/ and perhaps go to the https://lists.linux-foundation.org/pipermail/bridge/2011-May/thread.html list to ask for help if it is still broken in natty. + +Maverick gives me the same result. (Except I don't seem able, in maverick, to auto-setup the bond+bridge setup with /etc/network/interfaces, keep having to do it by hand. Hoping I did something wrong myself,a nd it's not a maverick bug) + +Natty is still affected. + +Since qemu isn't needed to show the bug, you can now trivially test this inside a natty kvm container by giving it two NICs, setting up /etc/network interfaces as shown above, and using lxc as follows: + + apt-get install lxc debootstrap + mkdir /cgroup + mount -t cgroup cgroup /cgroup + cat > /etc/lxc.conf << EOF + lxc.network.type=veth + lxc.network.link=br0 + lxc.network.flags=up + EOF + lxc-create -t natty -n lxc -f /etc/lxc.conf + lxc-start -n lxc + +When not using balance-rr, the container's network is fine. When using balance-rr, it can't get a dhcp address. + +Next step is probably to look at the hwaddr handling in the kernel source, and talk to upstream. + + +I sent an email to bonding-devel, and got this response: + +http://sourceforge.net/mailarchive/forum.php?thread_name=21866.1306527811%40death&forum_name=bonding-devel + +Assuming that your switch is in fact set up for Etherchannel, can you go ahead and gather the tcpdump data? + +I read the mail and did a first round of test before I could check the setting of the switch. Here are the transcript of the test with balance-rr. + +Container : LXC container with fixed IP +VMhost : The host where the LXC container runs. configured with br0 & bond0 +remote_host : another host on the same bridged subnet + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:40:49 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +VMhost : date;ping xxx.xxx.xxx.92 +Mon May 30 15:41:14 EDT 2011 +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=9 ttl=64 time=10.1 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=10 ttl=64 time=0.087 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=11 ttl=64 time=0.076 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +11 packets transmitted, 3 received, 72% packet loss, time 10004ms +rtt min/avg/max/mdev = 0.076/3.423/10.108/4.727 ms + + +Container : date;ping xxx.xxx.xxx.87 +Mon May 30 15:41:41 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +60 bytes from xxx.xxx.xxx.92: Destination Host Unreachable +Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data + 4 5 00 4c00 0000 0 0040 40 01 cc4e xxx.xxx.xxx.92 xxx.xxx.xxx.87 +^C--- xxx.xxx.xxx.87 ping statistics --- +4 packets transmitted, 0 packets received, 100% packet loss + + +remote_host : date;ping xxx.xxx.xxx.92 +lundi 30 mai 2011, 15:42:03 (UTC+0200) +PING xxx.xxx.xxx.92 (xxx.xxx.xxx.92) 56(84) bytes of data. +64 bytes from xxx.xxx.xxx.92: icmp_req=1 ttl=64 time=284 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=2 ttl=64 time=125 ms +64 bytes from xxx.xxx.xxx.92: icmp_req=3 ttl=64 time=134 ms +^C +--- xxx.xxx.xxx.92 ping statistics --- +3 packets transmitted, 3 received, 0% packet loss, time 2002ms +rtt min/avg/max/mdev = 125.282/181.561/284.952/73.204 ms + + +Container : Mon May 30 15:42:24 UTC 2011 +PING xxx.xxx.xxx.87 (xxx.xxx.xxx.87): 48 data bytes +56 bytes from xxx.xxx.xxx.87: icmp_seq=0 ttl=64 time=141.506 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=1 ttl=64 time=153.311 ms +56 bytes from xxx.xxx.xxx.87: icmp_seq=2 ttl=64 time=124.973 ms +^C--- xxx.xxx.xxx.87 ping statistics --- +3 packets transmitted, 3 packets received, 0% packet loss +round-trip min/avg/max/stddev = 124.973/139.930/153.311/11.622 ms + +I will send you the dump data directly. Now that I have full access to our switch, I will do more tests tomorrow. As far as I know, the switch is doing automatic trunking so the switch should not be an issue. + + +Hello, + +Now I am dazed and confused (and trying to continue) + +I have tested most of the combination of bonding modes with appropriate switch settings and here is what I get : + +Bonding mode switch configuration result(ping from Container) With STP +============ ==================== ====== ======== +balance-rr two port trunked OK +balance-rr No trunking NOK OK +balance-alb No trunking OK +balance-tlb No trunking OK +802.3ad LACP dynamic trunk OK +balance-xor two port trunked OK +balance-xor No trunking NOK NOK + +I could swear that I had tested -alb and -tlb with negative results. So apparently, the STP workaround is not required with proper switch configuration. + +It looks like this has been fixed upstream. I will close it. If the problem still occurs, please reopen it. + + diff --git a/results/classifier/108/other/786 b/results/classifier/108/other/786 new file mode 100644 index 000000000..f0526c334 --- /dev/null +++ b/results/classifier/108/other/786 @@ -0,0 +1,32 @@ +boot: 0.769 +files: 0.692 +device: 0.611 +graphic: 0.459 +semantic: 0.326 +network: 0.273 +socket: 0.226 +vnc: 0.221 +debug: 0.143 +PID: 0.110 +KVM: 0.099 +other: 0.075 +performance: 0.070 +permissions: 0.069 + +assert in qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Description of problem: +assert and crash when -acpitable argument is used. Specifically, the argument was "-acpitable file=my_file.bin" which causes the assert and crash. + +The other arguments, I hope, are not critical. In brief, I'm using secure boot (with ovmf_code.secboot.fd), and a sw tpm as well. But hopefully these are not relevant. + +The assert with -acpitable is a regression since it worked with version 6.1.0 + +The actual error message in qemu 6.2.0 is + +qemu-6.2.0/hw/acpi/aml-build.c:61:build_append_padded_str: assertion failed: (len <= maxlen) +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/108/other/786208 b/results/classifier/108/other/786208 new file mode 100644 index 000000000..7494baf38 --- /dev/null +++ b/results/classifier/108/other/786208 @@ -0,0 +1,30 @@ +device: 0.886 +performance: 0.835 +graphic: 0.759 +other: 0.727 +semantic: 0.704 +network: 0.654 +PID: 0.562 +permissions: 0.544 +debug: 0.506 +vnc: 0.493 +files: 0.468 +socket: 0.462 +boot: 0.384 +KVM: 0.246 + +Missing checks for non-existent device in ide_exec_cmd + +Several calls in the ide_exec_cmd handler are missing checks for (!s->bs) or similar, resulting in NULL pointer dereferences, divide-by-zero, or possibly other badness if the guest performs operations on a non-existent IDE master. + +For example, the WIN_READ_NATIVE_MAX command does a 'ide_set_sector(s, s->nb_sectors - 1);', which does 'cyl = sector_num / (s->heads * s->sectors);', which will fail with a divide-by-zero if heads = sectors = 0. + +And WIN_MULTREAD also does not check for s->bs, but does a 'ide_sector_read(s);', which will do 'bdrv_read(s->bs, sector_num, s->io_buffer, n);' on a NULL s->bs, leading to a segfault. + +I do not *believe* that a malicious guest can do anything more than cause a crash with these bugs. + +The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. +If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/786209 b/results/classifier/108/other/786209 new file mode 100644 index 000000000..165446b68 --- /dev/null +++ b/results/classifier/108/other/786209 @@ -0,0 +1,30 @@ +device: 0.810 +vnc: 0.649 +network: 0.605 +socket: 0.550 +graphic: 0.529 +semantic: 0.472 +performance: 0.439 +permissions: 0.389 +boot: 0.377 +other: 0.354 +PID: 0.326 +files: 0.287 +debug: 0.190 +KVM: 0.162 + +Information leak in IDE core + +When the DRQ_STAT bit is set, the IDE core permits both data reads and data writes, regardless of whether the current transfer was initiated as a read or write. + +Furthermore, the IO buffer is allocated via a qemu_memalign but not initialized or cleared at device creation. + +This potentially leaks uninitialized host memory into the guest, if, before doing anything else to an IDE device, the guest begins a write transaction (e.g. WIN_WRITE), but then *reads* from the IO port instead of writing to it. The IDE core will happily return the uninitialized contents of the buffer to the guest, potentially leaking offsets that could be used as part of an attack to get around ASLR. + +hi Nelson : + + what 's the flag 'DRQ_STAT' mean for HD_STATUS ? + +Fixed here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=40c4ed3f95f0b2ffa0848df0f + diff --git a/results/classifier/108/other/786440 b/results/classifier/108/other/786440 new file mode 100644 index 000000000..13745fc13 --- /dev/null +++ b/results/classifier/108/other/786440 @@ -0,0 +1,42 @@ +performance: 0.672 +device: 0.642 +semantic: 0.631 +graphic: 0.625 +debug: 0.478 +other: 0.451 +network: 0.442 +socket: 0.380 +permissions: 0.361 +PID: 0.234 +vnc: 0.201 +boot: 0.169 +files: 0.153 +KVM: 0.119 + +qcow2 double free + +version 0.14.1 when using qcow2 images, after some time, glibc detects a double free or corruption. + +On Sun, May 22, 2011 at 8:58 AM, Andrew Kroll <email address hidden> wrote: +> Public bug reported: +> +> version 0.14.1 when using qcow2 images, after some time, glibc detects a +> double free or corruption. + +Any specific information on what the guest was doing? Was it doing +heavy I/O or was it idle? + +Are you using IDE emulation or virtio-blk? + +Please provide a backtrace: +1. Build with ./configure --disable-strip (or use matching -debuginfo +packages from your distro) +2. Run with gdb --args path/to/qemu [...args...] + +When the abort happens please use the "bt" GDB command to display a backtrace. + +Stefan + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/786442 b/results/classifier/108/other/786442 new file mode 100644 index 000000000..c3494202b --- /dev/null +++ b/results/classifier/108/other/786442 @@ -0,0 +1,25 @@ +device: 0.768 +semantic: 0.708 +network: 0.667 +socket: 0.658 +other: 0.637 +debug: 0.612 +vnc: 0.604 +files: 0.560 +PID: 0.549 +permissions: 0.537 +boot: 0.505 +performance: 0.476 +graphic: 0.448 +KVM: 0.342 + +GCC -O2 causes segfaults + +unless compiled without optimizations, no system may be ran except the default with -kvm-enabled +I had to modify config-host.mak and remove -O2 from CFLAGS to be able to work without kvm. + +GCC 4.4.4 qemu-0.14.1 +***NOTE: this has been an issue for several versions. + +Sorry, that there were no reactions to this ticket when you've opened it. Since both, GCC 4.4 and QEMU 0.14 are quite outdated nowadays, and AFAIK nobody complains about this issue with newer versions anymore, I think we can close this bug nowadays. If you still have this problem with the latest version of QEMU, please feel free to open this ticket again. + diff --git a/results/classifier/108/other/787 b/results/classifier/108/other/787 new file mode 100644 index 000000000..a9d1d239b --- /dev/null +++ b/results/classifier/108/other/787 @@ -0,0 +1,27 @@ +device: 0.900 +graphic: 0.864 +performance: 0.767 +vnc: 0.759 +socket: 0.710 +PID: 0.686 +permissions: 0.662 +debug: 0.596 +files: 0.557 +network: 0.540 +boot: 0.536 +KVM: 0.457 +semantic: 0.452 +other: 0.334 + +6.2.0 Regression with Intel GVT-g +Description of problem: +Until version 6.1.0 the Intel GVT-g graphics passtrought was working flawless. But, since the version 6.2.0 the machine with the exact same configuration is not working anymore, presenting an error that the graphics device was not found. + +``` +qemu-system-x86_64: -set device.hostdev0.x-igd-opregion=on: there is no device "hostdev0" defined +``` + +Downgrade to 6.1.0 fixes the problem. +Steps to reproduce: +1. Create a virtual machine with GVT-g +2. Try to run the machine. diff --git a/results/classifier/108/other/788701 b/results/classifier/108/other/788701 new file mode 100644 index 000000000..8acaba51d --- /dev/null +++ b/results/classifier/108/other/788701 @@ -0,0 +1,31 @@ +graphic: 0.903 +device: 0.795 +network: 0.688 +performance: 0.686 +semantic: 0.600 +PID: 0.584 +socket: 0.569 +boot: 0.534 +other: 0.523 +vnc: 0.504 +files: 0.489 +permissions: 0.487 +debug: 0.431 +KVM: 0.136 + +qemu-user fails to run rpcgen (i386, x86_64) + +Confirmed on qemu current development tree (git commit aa29141). While trying to run eglibc's rpcgen from native system by qemu-user, I get an error: + +qemu-x86_64 /usr/bin/rpcgen -c /dev/null +fork: Invalid argument + +I am running a Debian Wheezy system and rpcgen comes from libc-dev-bin. Just in case I am attaching my rpcgen binaries from i386 and x86_64 systems. + +Very similar problem was mentioned on the QEMU forum on February 2007, so I guess it might be a known issue. Nevertheless, I was unable to find any information about bug reports, fixes nor workarounds for it so I'm reporting it here. + + + +This should be fixed in QEMU 1.6. + + diff --git a/results/classifier/108/other/788881 b/results/classifier/108/other/788881 new file mode 100644 index 000000000..6ca5a17ef --- /dev/null +++ b/results/classifier/108/other/788881 @@ -0,0 +1,34 @@ +graphic: 0.867 +semantic: 0.828 +performance: 0.762 +device: 0.740 +PID: 0.680 +other: 0.612 +files: 0.601 +debug: 0.550 +network: 0.519 +vnc: 0.467 +boot: 0.423 +socket: 0.392 +permissions: 0.319 +KVM: 0.044 + +i386-bsd-user and similar don't build on Mac OS X + +0.14.1 crashes on Mac OS X 64bit with some targets (*-bsd-user): + + CC i386-bsd-user/cpu-exec.o +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c: In function ‘cpu_x86_signal_handler’: +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: ‘REG_RIP’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: (Each undeclared identifier is reported only once +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: for each function it appears in.) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: ‘REG_TRAPNO’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: ‘REG_ERR’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:899: error: dereferencing pointer to incomplete type +make[1]: *** [cpu-exec.o] Error 1 + +The bsd-user target is currently unmainted in QEMU, and I think it is not meant for Mac OS X, but rather for FreeBSD and friends. So let's close this ticket now... + diff --git a/results/classifier/108/other/788886 b/results/classifier/108/other/788886 new file mode 100644 index 000000000..5ff46601a --- /dev/null +++ b/results/classifier/108/other/788886 @@ -0,0 +1,28 @@ +graphic: 0.851 +device: 0.725 +semantic: 0.519 +network: 0.514 +permissions: 0.450 +performance: 0.433 +vnc: 0.433 +debug: 0.338 +files: 0.311 +other: 0.253 +PID: 0.238 +boot: 0.232 +socket: 0.179 +KVM: 0.015 + +Crash with -m32 and gcc-4.2 on Mac OS X 64bit + +For building 32bit Qemu on Mac OS X 10.6.7 , i configure with --extra-cflags=-m32 --extra-ldflags=-m32. make with gcc-4.2 then crashes with: + + GEN qemu-options.def + CC qemu-nbd.o +gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags +make: *** [qemu-nbd.o] Error 1 + +Which version of QEMU were you using? Can you still reproduce this problem with the latest version of QEMU and the latest version of macOS? + +[Expired for QEMU because there has been no activity for 60 days.] + |