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 channels

>>> 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?

Thanks, Jan

Xen-devel mailing list

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