[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 16:07:20 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
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