On 23/06/2015 16:21, Frederic Konrad wrote:
>
>> While I was testing multi-threaded TCG I discovered once consequence of
>> using locking around memory_region_dispatch is that virt-io transactions
>> could dead lock trying to grab the main mutex. This is due to the
>> virt-io driver writing data back into the system memory:
>
> Hi,
>
> Thanks for that.
> Didn't qemu abort in this case with a pthread error? Maybe that did
> change since
> the last time I had this error.
Unfortunately it had to change:
commit 24fa90499f8b24bcba2960a3316d797f9b80b5e9
Author: Paolo Bonzini <pbonz...@redhat.com>
Date: Thu Mar 5 16:47:14 2015 +0100
qemu-thread: do not use PTHREAD_MUTEX_ERRORCHECK
PTHREAD_MUTEX_ERRORCHECK is completely broken with respect to fork.
The way to safely do fork is to bring all threads to a quiescent
state by acquiring locks (either in callers---as we do for the
iothread mutex---or using pthread_atfork's prepare callbacks)
and then release them in the child.
The problem is that releasing error-checking locks in the child
fails under glibc with EPERM, because the mutex stores a different
owner tid than the duplicated thread in the child process. We
could make it work for locks acquired via pthread_atfork, by
recreating the mutex in the child instead of unlocking it
(we know that there are no other threads that could have taken
the mutex; but when the lock is acquired in fork's caller
that would not be possible.
The simplest solution is just to forgo error checking.
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
I do revert that patch however for my own testing, since it does make
things much easier when there's a deadlock.
Paolo
