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

[Peter Maydell]

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).

thanks
-- PMM