Commit 73a988d9 authored by Max Filippov's avatar Max Filippov
Browse files

linux-user: call cpu_copy under clone_lock 



cpu_copy adds newly created CPU object to container/machine/unattached,
but does it w/o proper locking. As a result when multiple threads create
threads rapidly QEMU may abort with the following message:

  GLib-CRITICAL **: g_hash_table_iter_next: assertion
  'ri->version == ri->hash_table->version' failed

  ERROR:qemu/qom/object.c:1663:object_get_canonical_path_component:
  code should not be reached

E.g. this issue is observed when running glibc test nptl/tst-eintr1.
Move cpu_copy invocation under clone_lock to fix that.

Reviewed-by: default avatarLaurent Vivier <laurent@vivier.eu>
Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
parent 4a6bf7ad

linux-user/syscall.c

+4 −3
Original line number Diff line number Diff line
@@ -6346,6 +6346,10 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp, 


        ts = g_new0(TaskState, 1);

        init_task_state(ts);



        /* Grab a mutex so that thread setup appears atomic.  */

        pthread_mutex_lock(&clone_lock);



        /* we create a new CPU instance. */

        new_env = cpu_copy(env);

        /* Init regs that differ from the parent.  */
@@ -6364,9 +6368,6 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp, 
            cpu_set_tls (new_env, newtls);

        }



        /* Grab a mutex so that thread setup appears atomic.  */

        pthread_mutex_lock(&clone_lock);



        memset(&info, 0, sizeof(info));

        pthread_mutex_init(&info.mutex, NULL);

        pthread_mutex_lock(&info.mutex);