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: Jan Beulich <JBeulich@xxxxxxxxxx>, Daniel Stodden <Daniel.Stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] Fix lost interrupt race in Xen event channels
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 30 Aug 2010 09:48:40 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Tom Kopec <tek@xxxxxxx>
Delivery-date: Mon, 30 Aug 2010 01:50:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C7B8B520200007800012C31@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActIH2vMMM1v9jfLRyGoC5mO5ZPmngAALjHR
Thread-topic: [Xen-devel] [GIT PULL] Fix lost interrupt race in Xen event channels
User-agent: Microsoft-Entourage/
On 30/08/2010 09:43, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> On 30.08.10 at 10:03, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> Helpful would be if the function returned whether it actually went
>> through the mask/unmask pair, as I'm not sure the double
>> unmasking really is a good idea, especially in the PIRQ case (for
>> the moment I'm considering putting an already-unmasked check
>> into both ->eoi() handlers).
> Actually, it seems to me that this check really (also) belongs into
> unmask_evtchn(). Keir (I think you wrote this code originally), is
> there a reason (other than the implied assumption that it won't
> get called on an already unmasked event channel) the function
> uses sync_clear_bit() rather than sync_test_and_clear_bit(),
> doing the other actions only if the bit wasn't already clear, just
> like Xen itself does for the respective hypercall implementation?

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

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>