summaryrefslogtreecommitdiffstats
path: root/hw/usb
diff options
context:
space:
mode:
authorPaolo Bonzini2015-02-27 19:58:23 +0100
committerPaolo Bonzini2015-03-02 10:57:07 +0100
commit6b49809c597331803ea941eadda813e5bb4e8fe2 (patch)
tree20c4918782dc9ffeb186a1da2f40e8e47e92738e /hw/usb
parentvirtio-scsi: Allocate op blocker reason before blocking (diff)
downloadqemu-6b49809c597331803ea941eadda813e5bb4e8fe2.tar.gz
qemu-6b49809c597331803ea941eadda813e5bb4e8fe2.tar.xz
qemu-6b49809c597331803ea941eadda813e5bb4e8fe2.zip
cpus: fix deadlock and segfault in qemu_mutex_lock_iothread
When two threads (other than the low-priority TCG VCPU thread) are competing for the iothread lock, a deadlock can happen. This is because iothread_requesting_mutex is set to false by the first thread that gets the mutex, and then the VCPU thread might never yield from the execution loop. If iothread_requesting_mutex is changed from a bool to a counter, the deadlock is fixed. However, there is another bug in qemu_mutex_lock_iothread that can be triggered by the new call_rcu thread. The bug happens if qemu_mutex_lock_iothread is called before the CPUs are created. In that case, first_cpu is NULL and the caller segfaults in qemu_mutex_lock_iothread. To fix this, just do not do the kick if first_cpu is NULL. Reported-by: Leon Alrae <leon.alrae@imgtec.com> Reported-by: Andreas Gustafsson <gson@gson.org> Tested-by: Leon Alrae <leon.alrae@imgtec.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw/usb')
0 files changed, 0 insertions, 0 deletions