linux-user: Fix locking order in fork_start()
commit024949caf32805f4cc3e7d363a80084b47aac1f6
authorPeter Maydell <peter.maydell@linaro.org>
Mon, 4 Dec 2017 14:22:11 +0000 (4 14:22 +0000)
committerLaurent Vivier <laurent@vivier.eu>
Tue, 23 Jan 2018 13:20:52 +0000 (23 14:20 +0100)
tree28b0ba5b4593d78eacdc49b9627e9cf0e61e54a6
parent52483b067cce4a88ffbf8fbeea26de7549d2ad23
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 <peter.maydell@linaro.org>
Cc: qemu-stable@nongnu.org
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <1512397331-15238-1-git-send-email-peter.maydell@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
linux-user/main.c