From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH 0 of 3] Remus: control tool Date: Tue, 01 Dec 2009 15:04:49 -0800 Message-ID: <4B15A111.1050004@goop.org> References: <20091113141859.GB23952@phenom.dumpdata.com> <20091113213627.GD11642@kremvax.cs.ubc.ca> <20091201152012.GY16033@reaktio.net> <20091201161619.GA2438@zanzibar.quuxuum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091201161619.GA2438@zanzibar.quuxuum.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: pasik@iki.fi, konrad.wilk@oracle.com, xen-devel@lists.xensource.com, andy@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org On 12/01/09 08:16, Brendan Cully wrote: > I'll probably take a crack at this soon. From a quick look at the > pvops suspend code, it seems like it may suffer from a race when > multiple suspends are issued that Keir fixed in the 2.6.18 tree some > time ago -- it'd be better to get that fixed before porting the event > channel patch. > What's the bug? I don't see a reentrancy issue there because the suspend happens synchronously in the xenwatch thread under xenwatch_mutex. Or race for that matter. Am I missing something? Of course, if you start triggering suspends via event channels, we'll need to work out something else. J