On 05/12/2017 16:01, Peter Maydell wrote: > On 5 December 2017 at 13:19, Paolo Bonzini <pbonz...@redhat.com> 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
