|
From: | David Engraf |
Subject: | Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized |
Date: | Wed, 25 Nov 2015 16:48:24 +0100 |
Am 25.11.2015 um 15:36 schrieb Paolo Bonzini:
On 25/11/2015 15:04, David Engraf wrote:No, you don't. Who is reading iothread_locked during qemu_cond_wait_iothread? No one, because it is a thread-local variable whose address is never taken.prepare_mmio_access is reading iothread_locked by using qemu_mutex_iothread_locked after qemu_tcg_wait_io_event calls qemu_cond_wait. All one the same thread.Sure, but who has set iothread_locked to false during the execution of qemu_cond_wait? No one, because it's a thread-local variable. If it's true before qemu_cond_wait, it will be true after qemu_cond_wait and you don't need qemu_cond_wait_iothread... unless your compiler is broken and doesn't generate TLS properly.
Indeed, TLS handling is broken. The address of iothread_locked is always the same between threads and I can see that a different thread sets iothread_locked to false, thus my current thread uses an invalid state. I will have to check why my compiler produces invalid TLS code.
David
Can you compile cpus.c with -S and attach it? Paoloqemu_tcg_cpu_thread_fn -> qemu_tcg_wait_io_event -> qemu_cond_wait acquires the mutex qemu_tcg_cpu_thread_fn -> tcg_exec_all -> tcg_cpu_exec -> cpu_exec -> cpu_exec ends up in calling prepare_mmio_access
[Prev in Thread] | Current Thread | [Next in Thread] |