From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister Date: Mon, 10 Dec 2012 10:19:26 +0000 Message-ID: <1355134766.31710.119.camel@zakaz.uk.xensource.com> References: <0451e6041bdd88c90eee.1353395794@linux-bjrd.bjz> <20661.3989.258191.396175@mariner.uk.xensource.com> <1354101923.25834.16.camel@zakaz.uk.xensource.com> <20674.16214.934271.479230@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20674.16214.934271.479230@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: "jfehlig@suse.com" , "xen-devel@lists.xen.org" , Bamvor Jian Zhang List-Id: xen-devel@lists.xenproject.org On Fri, 2012-12-07 at 19:11 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH] fix race condition between libvirtd event handling and libxl fd deregister"): > > Can we provide, or (more likely) require the application to provide, a > > lock (perhaps per-event or, again more likely, per-event-loop) which > > must be held while processing callbacks and also while events are being > > registered/unregistered with the application's event handling subsystem? > > With such a lock in place the application would be able to guarantee > > that having returned from the deregister hook any further events would > > be seen as spurious events by its own event processing loop. > > I think this might be difficult to get right without deadlocks. I took Bamvor's most recent response to mean that a per-event lock was already in place in libvirt and inferred that this was the reason why the originally proposed one line fix worked for them. Perhaps I misunderstood? Ian.