From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [GIT PULL] Fix lost interrupt race in Xen event channels Date: Mon, 30 Aug 2010 09:36:31 -0700 Message-ID: <4C7BDE0F.1010305@goop.org> References: <4C743B2C.8070208@goop.org> <4C74E7C802000078000120C0@vpn.id2.novell.com> <4C7558E0.1060806@goop.org> <4C7629D10200007800012387@vpn.id2.novell.com> <4C769736.4050409@goop.org> <4C7799EB020000780001276F@vpn.id2.novell.com> <1282941781.26797.386.camel@agari.van.xensource.com> <4C7B81FB0200007800012C16@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C7B81FB0200007800012C16@vpn.id2.novell.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: Jan Beulich Cc: "Xen-devel@lists.xensource.com" , Tom Kopec , Daniel Stodden List-Id: xen-devel@lists.xenproject.org On 08/30/2010 01:03 AM, Jan Beulich wrote: > This totals to it having been wrong to break up -mask() and ->ack() - > when using the combined ->mask_ack() (like in XCP etc) it would have > been pretty obvious that move_native_irq() cannot go between > mask() and ack(). Probably, but I just viewed the mask_ack() as an optimisation that didn't need to be addressed on the first pass. I converted the basic event channels to fasteoi and it seems to work OK. I'll look at pirq today. > For us, using fasteoi, move_native_irq() sits in ->eoi(), before > un-masking. One could, as Jeremy suggests, call move_masked_irq() > here, but I didn't want to duplicate the IRQ_DISABLED check done > in move_native_irq(), mainly to not depend on following potential > future changes (additions) to the set of conditions checked there. Is there actually a problem with moving a IRQ_DISABLED interrupt? If so, shouldn't that IRQ_DISABLED check also be in move_masked_irq()? J