From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZULa1-0000ke-U8 for qemu-devel@nongnu.org; Tue, 25 Aug 2015 17:16:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZULZy-0003Px-O9 for qemu-devel@nongnu.org; Tue, 25 Aug 2015 17:16:29 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:42816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZULZy-0003Pb-Fo for qemu-devel@nongnu.org; Tue, 25 Aug 2015 17:16:26 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B5C1820F5F for ; Tue, 25 Aug 2015 17:16:25 -0400 (EDT) Date: Tue, 25 Aug 2015 17:16:48 -0400 From: "Emilio G. Cota" Message-ID: <20150825211648.GC29063@flamenco> References: <1440375847-17603-1-git-send-email-cota@braap.org> <1440375847-17603-25-git-send-email-cota@braap.org> <55DA7B03.2040707@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DA7B03.2040707@redhat.com> Subject: Re: [Qemu-devel] [RFC 24/38] cpu-exec: reset mmap_lock after exiting the CPU loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, alex.bennee@linaro.org, Frederic Konrad On Sun, Aug 23, 2015 at 19:01:39 -0700, Paolo Bonzini wrote: > On 23/08/2015 17:23, Emilio G. Cota wrote: > > Otherwise after an exception we end up in a deadlock. > > Can you explain better the path that exits cpu_exec with the lock taken? In fact I cannot :-) So please ignore this patch. I wrote this while rebasing my code on top of your mttcg branch, and then it was needed. However, patch 01/38 (which I wrote after writing this patch) was the right fix, and I forgot to check whether this patch was still necessary--turns out it wasn't. > Also, let's remove the recursive locking by introducing "mmap_lock() > already taken" variants of target_mprotect and target_mmap. Will do. Thanks, Emilio