From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [GIT PULL] Fix lost interrupt race in Xen event channels Date: Mon, 30 Aug 2010 10:06:07 +0100 Message-ID: <4C7B909F0200007800012C52@vpn.id2.novell.com> References: <4C7B8B520200007800012C31@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Jeremy Fitzhardinge , "Xen-devel@lists.xensource.com" , Tom Kopec , Daniel Stodden List-Id: xen-devel@lists.xenproject.org >>> On 30.08.10 at 10:48, Keir Fraser wrote: > Well, in 2.6.18 it was at least very unlikely that unmask_evtchn() would = be > called on an already-unmasked port. And the implementation of > unmask-evtchn() is safe in the case that it is called for an > already-unmasked port -- it just does a bit more work than necessary in = that > case. ... plus possibly causes an unnecessary upcall. However, do you also think that pirq_unmask_and_notify() is safe to be called twice? I would think the double EOI potentially sent to Xen could lead to an interrupt getting ack-ed that didn't even get started to be serviced yet. And this, afaict, can happen in 2.6.18 as well (ack_pirq() -> move_native_irq() -> disable_pirq()/ enable_pirq() -> pirq_unmask_and_notify() followed by end_pirq() -> pirq_unmask_and_notify()). Here, however, you couldn't even use the mask bit to detect the situation, since the masking only happens after already having called move_native_irq() (i.e. the event channel will be masked when you get into pirq_unmask_and_notify() the second time). Jan