From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upatj-0003ZD-Sd for qemu-devel@nongnu.org; Thu, 20 Jun 2013 05:11:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upath-0004aU-To for qemu-devel@nongnu.org; Thu, 20 Jun 2013 05:11:19 -0400 Received: from mail-wg0-x230.google.com ([2a00:1450:400c:c00::230]:63631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upath-0004aJ-NX for qemu-devel@nongnu.org; Thu, 20 Jun 2013 05:11:17 -0400 Received: by mail-wg0-f48.google.com with SMTP id f11so5288395wgh.15 for ; Thu, 20 Jun 2013 02:11:17 -0700 (PDT) Date: Thu, 20 Jun 2013 11:11:13 +0200 From: Stefan Hajnoczi Message-ID: <20130620091113.GB15672@stefanha-thinkpad.redhat.com> References: <1371381681-14252-1-git-send-email-pingfanl@linux.vnet.ibm.com> <1371381681-14252-3-git-send-email-pingfanl@linux.vnet.ibm.com> <20130618151438.GA12685@vm> <51C0B2FA.4090808@redhat.com> <20130618222652.GC7866@vm> <51C1797D.9080800@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51C1797D.9080800@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 2/2] QEMUBH: make AioContext's bh re-entrant List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, mdroth , Anthony Liguori , Liu Ping Fan On Wed, Jun 19, 2013 at 11:27:25AM +0200, Paolo Bonzini wrote: > Il 19/06/2013 00:26, mdroth ha scritto: > > On Tue, Jun 18, 2013 at 09:20:26PM +0200, Paolo Bonzini wrote: > >> Il 18/06/2013 17:14, mdroth ha scritto: > >>> Could we possibly simplify this by introducing a recursive mutex that we > >>> could use to protect the whole list loop and hold even during the cb? > >> > >> If it is possible, we should avoid recursive locks. It makes impossible > >> to establish a lock hierarchy. For example: > >> > >>> I assume we can't hold the lock during the cb currently since we might > >>> try to reschedule, but if it's a recursive mutex would that simplify > >>> things? > >> > >> If you have two callbacks in two different AioContexts, both of which do > >> bdrv_drain_all(), you get an AB-BA deadlock > > > > I think I see what you mean. That problem exists regardless of whether we > > introduce a recursive mutex though right? > > Without a recursive mutex, you only hold one lock at a time in each thread. > > > I guess the main issue is the > > fact that we'd be encouraging sloppy locking practices without > > addressing the root problem? > > Yeah. We're basically standing where the Linux kernel stood 10 years > ago (let's say 2.2 timeframe). If Linux got this far without recursive > mutexes, we can at least try. :) FWIW I was also looking into recursive mutexes for the block layer. What scared me a little is that they make it tempting to stop thinking about locks since you know you'll be able to reacquire locks you already hold. Especially when converting existing code, I think we need to be rigorous about exploring every function and thinking about the locks it needs and which child functions it calls. Otherwise we'll have code paths hidden away somewhere that were never truly thought through. Stefan