From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1edzs1-00075Q-17 for qemu-devel@nongnu.org; Tue, 23 Jan 2018 09:48:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1edzrw-0002JX-QB for qemu-devel@nongnu.org; Tue, 23 Jan 2018 09:48:17 -0500 From: Laurent Vivier Date: Tue, 23 Jan 2018 15:47:55 +0100 Message-Id: <20180123144807.5618-2-laurent@vivier.eu> In-Reply-To: <20180123144807.5618-1-laurent@vivier.eu> References: <20180123144807.5618-1-laurent@vivier.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] [PULL 01/13] linux-user: Fix locking order in fork_start() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , qemu-stable@nongnu.org, Laurent Vivier From: Peter Maydell 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 --- linux-user/main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 450eb3ce65..e8406917e3 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -127,9 +127,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) -- 2.14.3