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

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 30/08/2010 09:43, "Jan Beulich" <JBeulich@novell.com> wrote:

>>>> On 30.08.10 at 10:03, "Jan Beulich" <JBeulich@novell.com> 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
case.

 -- Keir