From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cJ6-0005jd-Fk for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:48:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1cJ1-0006IB-SF for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:48:32 -0500 Received: from mail.sysgo.com ([176.9.12.79]:45823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cJ1-0006Go-Lx for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:48:27 -0500 References: <565485A0.5090902@sysgo.com> <5654883F.9050509@redhat.com> <56557AA2.9080100@sysgo.com> <5655AA1F.8060906@sysgo.com> <5655B706.6060306@redhat.com> <5655BFEA.50407@sysgo.com> <5655C781.8090201@redhat.com> From: David Engraf Message-ID: <5655D848.9050104@sysgo.com> Date: Wed, 25 Nov 2015 16:48:24 +0100 MIME-Version: 1.0 In-Reply-To: <5655C781.8090201@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qemu_mutex_iothread_locked not correctly synchronized List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: Fam Zheng 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? > > Paolo > >> qemu_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