Re: [Qemu-devel] deadlock in rcu_init_lock() in usermode emulation

[Paolo Bonzini]

On 05/12/2017 16:01, Peter Maydell wrote:
> On 5 December 2017 at 13:19, Paolo Bonzini <address@hidden> wrote:
>> Probably the best solution is to add start_exclusive/end_exclusive
>> respectively at the beginning and the end of fork_start and fork_end.
>> This is safer in general, as it ensures that the disappeared child
>> threads were quiescent.
>>
>> In fact, I wonder if fork_start/fork_end still need to "take all
>> mutexes" (in pthread_atfork style) if we do
>> start_exclusive/end_exclusive in fork_start and fork_end(0).  You don't
>> even need to reinitialize the mutexes, meaning that mmap_fork_start and
>> mmap_fork_end should go as well.
>>
>> The list of locks that are "assured not taken" within
>> start_exclusive/end_exclusive (currently: rcu_read_lock, tb_lock,
>> mmap_lock) should probably be documented in fork_start/fork_end.
> 
> How does start_exclusive() assure that mmap_lock and tb_lock
> aren't taken? It ensures that no other thread is between
> cpu_exec_start and cpu_exec_end, but we don't (can't) do the work of
> do_syscall() inside an exec-start/end section, and do_syscall()
> codepaths can take the mmap lock and the tb lock (eg target_mmap()
> will take the mmap lock and then call tb_invalidate_phys_range()
> which takes the tb lock).

You're right of course---I'm not very well versed in user-mode
emulation.  But it should still fix the bug.

Paolo