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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel