Re: [Qemu-devel] [RFC PATCH] qemu_mutux: make the iothread recursive (MTTCG)

[Paolo Bonzini <pbonzini@redhat.com>]

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 <pbonzini@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 <pbonzini@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