From: Peter Maydell Date: Mon, 4 Dec 2017 14:22:11 +0000 (+0000) Subject: linux-user: Fix locking order in fork_start() X-Git-Tag: v2.11.1~54 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9327a8e2d639370960c1dc3e11ff5d9c2b26174c;p=thirdparty%2Fqemu.git linux-user: Fix locking order in fork_start() Our locking order is that the tb lock should be taken inside the mmap_lock, but fork_start() grabs locks the other way around. This means that if a heavily multithreaded guest process (such as Java) calls fork() it can deadlock, with the thread that called fork() stuck in fork_start() with the tb lock and waiting for the mmap lock, but some other thread in tb_find() with the mmap lock and waiting for the tb lock. The cpu_list_lock() should also always be taken last, not first. Fix this by making fork_start() grab the locks in the right order. The order in which we drop locks doesn't matter, so we leave fork_end() the way it is. Signed-off-by: Peter Maydell Cc: qemu-stable@nongnu.org Reviewed-by: Paolo Bonzini Reviewed-by: Alex Bennée Message-Id: <1512397331-15238-1-git-send-email-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier (cherry picked from commit 024949caf32805f4cc3e7d363a80084b47aac1f6) Signed-off-by: Michael Roth --- diff --git a/linux-user/main.c b/linux-user/main.c index 6286661bd36..146ee3e4ba6 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -128,9 +128,9 @@ int cpu_get_pic_interrupt(CPUX86State *env) /* Make sure everything is in a consistent state for calling fork(). */ void fork_start(void) { - cpu_list_lock(); - qemu_mutex_lock(&tb_ctx.tb_lock); mmap_fork_start(); + qemu_mutex_lock(&tb_ctx.tb_lock); + cpu_list_lock(); } void fork_end(int child)