From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ahc-0007be-Cc for qemu-devel@nongnu.org; Thu, 18 Jun 2015 10:22:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5ahV-0007Rz-Au for qemu-devel@nongnu.org; Thu, 18 Jun 2015 10:22:00 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:48767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5ahV-0007QK-1i for qemu-devel@nongnu.org; Thu, 18 Jun 2015 10:21:53 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4CC2A20963 for ; Thu, 18 Jun 2015 10:21:51 -0400 (EDT) Date: Thu, 18 Jun 2015 10:23:09 -0400 From: "Emilio G. Cota" Message-ID: <20150618142309.GA12305@flamenco> References: <20150617005222.GA18884@flamenco> <20150617213625.GA16082@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] linux-user crashes on clone(2) when run on ppc host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Riku Voipio , "qemu-ppc@nongnu.org" , Alexander Graf , QEMU Developers On Thu, Jun 18, 2015 at 08:42:40 +0100, Peter Maydell wrote: > > What data structures are you referring to? Are they ppc-specific? > > None of the code generation data structures are locked at all -- > if two threads try to generate code at the same time they'll > tend to clobber each other. AFAICT tb_gen_code is called with a mutex held (the sequence is mutex->tb_find_fast->tb_find_slow->tb_gen_code in cpu-exec.c) The only call to tb_gen_code that in usermode is not holding the lock is in cpu_breakpoint_insert->breakpoint_invalidate-> tb_invalidate_phys_page_range->tb_gen_code. I'm not using gdb so I guess I cannot trigger this. Am I missing something? > On 17 June 2015 at 22:36, Emilio G. Cota wrote: > > I don't think this is a race because it also breaks when > > run on a single core (with taskset -c 0). As I said, this problem doesn't seem to be a race. Thanks, Emilio