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

[Paolo Bonzini]

On 04/12/2017 18:13, Peter Maydell wrote:
> Hi; in https://bugs.linaro.org/show_bug.cgi?id=3259 comment 27
> Stuart provides backtraces of a deadlock in user-mode in the RCU
> code.
> 
> How should this deadlock be broken ?

Summing up:

- fork thread: has mmap_lock, waits for rcu_sync_lock

- RCU thread: has rcu_sync_lock, waits for rcu_read_(un)lock

- another CPU thread: in RCU critical section, waits for mmap_lock

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.

Thanks,

Paolo