From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH 2/2] libxl: fix stale timeout event callback race Date: Thu, 13 Dec 2012 09:53:21 -0700 Message-ID: <50CA0801.2040901@suse.com> References: <20678.5159.946248.90947@mariner.uk.xensource.com> <1355158624-11163-2-git-send-email-ian.jackson@eu.citrix.com> <50C7B974.4050706@suse.com> <20680.47971.962603.851882@mariner.uk.xensource.com> <50C8BE3F.4040402@suse.com> <20680.49391.646654.814456@mariner.uk.xensource.com> <50C8C665.2030202@suse.com> <1355394576.10554.62.camel@zakaz.uk.xensource.com> <50C9F9EA.7020408@suse.com> <20681.64322.738705.484310@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20681.64322.738705.484310@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: Bamvor Jian Zhang , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Ian Jackson wrote: > Jim Fehlig writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix stale timeout event callback race"): > >> Ian Campbell wrote: >> >>> One option is to add new hooks which libxl can call to take/release the >>> application's event loop lock + a LIBXL_HAVE_EVENT_LOOP_LOCK define so >>> the application can conditionally provide them. >>> >> libvirt's event loop lock is private to the event impl and not exposed >> to its numerous users. >> > > Right. I still think it might be useful to provide a way for a > consenting application to allow libxl to use the application's event > loop lock (perhaps, its single giant lock) as the ctx lock. If it had > been possible in this case it would have eliminated these particular > races, so it's a benefit for those applications. And the extra > complexity doesn't seem likely to introduce other bugs. > > But I think we should fault that feature in when we have a potential > user for it, and from what you say that's not libvirt. > Correct. That approach doesn't really fit with libvirt's generic event loop used by the various drivers. I suppose the libxl driver could have a private event loop, but I'd prefer to keep the pattern used by other drivers. Regards, Jim