[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-stable] [PULL 01/13] linux-user: Fix locking order in fork_start()
From: |
Laurent Vivier |
Subject: |
[Qemu-stable] [PULL 01/13] linux-user: Fix locking order in fork_start() |
Date: |
Tue, 23 Jan 2018 15:47:55 +0100 |
From: Peter Maydell <address@hidden>
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 <address@hidden>
Cc: address@hidden
Reviewed-by: Paolo Bonzini <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
---
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-stable] [PULL 01/13] linux-user: Fix locking order in fork_start(),
Laurent Vivier <=