Commit 06065c45 authored by Peter Maydell's avatar Peter Maydell Committed by Laurent Vivier
Browse files

linux-user: wrap fork() in a start/end exclusive section 



When we do a fork() in usermode emulation, we need to be in
a start/end exclusive section, so that we can ensure that no
other thread is in an RCU section. Otherwise you can get this
deadlock:

- fork thread: has mmap_lock, waits for rcu_sync_lock
  (because rcu_init_lock() is registered as a pthread_atfork() hook)
- RCU thread: has rcu_sync_lock, waits for rcu_read_(un)lock
- another CPU thread: in RCU critical section, waits for mmap_lock

This can show up if you have a heavily multithreaded guest program
that does a fork().

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reported-by: default avatarStuart Monteith <stuart.monteith@linaro.org>
Message-Id: <1512650481-1723-1-git-send-email-peter.maydell@linaro.org>
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
parent 024949ca

linux-user/main.c

+5 −0
Original line number Diff line number Diff line
@@ -127,6 +127,7 @@ int cpu_get_pic_interrupt(CPUX86State *env) 
/* Make sure everything is in a consistent state for calling fork().  */

void fork_start(void)

{

    start_exclusive();

    mmap_fork_start();

    qemu_mutex_lock(&tb_ctx.tb_lock);

    cpu_list_lock();
@@ -147,9 +148,13 @@ void fork_end(int child) 
        qemu_mutex_init(&tb_ctx.tb_lock);

        qemu_init_cpu_list();

        gdbserver_fork(thread_cpu);

        /* qemu_init_cpu_list() takes care of reinitializing the

         * exclusive state, so we don't need to end_exclusive() here.

         */

    } else {

        qemu_mutex_unlock(&tb_ctx.tb_lock);

        cpu_list_unlock();

        end_exclusive();

    }

}