From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEHVG-0008Vy-MI for qemu-devel@nongnu.org; Wed, 19 Sep 2012 06:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEHVF-0006KC-PO for qemu-devel@nongnu.org; Wed, 19 Sep 2012 06:27:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44062) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEHVF-0006K5-FU for qemu-devel@nongnu.org; Wed, 19 Sep 2012 06:27:33 -0400 Message-ID: <50599E0E.7010704@redhat.com> Date: Wed, 19 Sep 2012 13:27:26 +0300 From: Avi Kivity MIME-Version: 1.0 References: <50597D1F.3070607@redhat.com> <50598B58.4010704@redhat.com> <50598D0D.2090608@redhat.com> <50598EB2.5040101@redhat.com> <505995B7.4010709@redhat.com> <5059993C.1070506@redhat.com> <50599C25.1020904@redhat.com> In-Reply-To: <50599C25.1020904@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Jan Kiszka , Marcelo Tosatti , liu ping fan , Anthony Liguori , qemu-devel@nongnu.org On 09/19/2012 01:19 PM, Paolo Bonzini wrote: > Il 19/09/2012 12:06, Avi Kivity ha scritto: >>> > (The hunch is that ts could be deleted exactly at the moment the >>> > callback is unlocked. This can be solved with ref/unref on the opaque >>> > value, as you mention below). >> Are you saying that this works as is or not? It does seem broken wrt >> deletion; after qemu_del_timer() completes the caller expects the >> callback not to be called. > > Ouch, then I think the only solution is to remove this invariant if you > add fine-grained locking and re-check the enable conditions in the timer > callback. I think so too, I know authors of GUI frameworks suffer from this problem (the GUI calling into the framework vs. the framework asking the GUI to repaint). Don't know what the state of the art solution is. > > If you allow calling del_timer to be called with the device lock held, > you cannot fixing without deadlocking. If you don't, the caller of > del_timer cannot set any expectation because the timer could be run in > the window between dropping the device lock and calling del_timer > Right. Callbacks should check qemu_timer_deleted() after taking their little lock. The reference held by the timer subsystem protects against qemu_free_timer(). -- error compiling committee.c: too many arguments to function