This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [GIT PULL] Fix lost interrupt race in Xen event channel

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] Fix lost interrupt race in Xen event channels
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 30 Aug 2010 10:06:07 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Tom Kopec <tek@xxxxxxx>, Daniel Stodden <Daniel.Stodden@xxxxxxxxxx>
Delivery-date: Mon, 30 Aug 2010 02:06:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8A12EF8.2154D%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C7B8B520200007800012C31@xxxxxxxxxxxxxxxxxx> <C8A12EF8.2154D%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 30.08.10 at 10:48, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 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).


Xen-devel mailing list