[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] deadlock in rcu_init_lock() in usermode emulation
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] deadlock in rcu_init_lock() in usermode emulation |
Date: |
Tue, 5 Dec 2017 14:19:10 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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