diff options
author | Paolo Bonzini | 2015-02-27 19:58:23 +0100 |
---|---|---|
committer | Paolo Bonzini | 2015-03-02 10:57:07 +0100 |
commit | 6b49809c597331803ea941eadda813e5bb4e8fe2 (patch) | |
tree | 20c4918782dc9ffeb186a1da2f40e8e47e92738e /hw/usb/dev-network.c | |
parent | virtio-scsi: Allocate op blocker reason before blocking (diff) | |
download | qemu-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/dev-network.c')
0 files changed, 0 insertions, 0 deletions