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

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

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

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

Erm, well if this is a race that happens only occasionally, does it matter?
Worst case you get another interrupt straight away. Only a problem if it
happens often enough to cause a performance issue or even livelock interrupt
storm.

The obvious fix would be for the kernel to privately keep track of which
event channels or pirqs are masked and/or disabled (e.g., with two bitflags
per port). Then have the evtchn_mask flag be the OR of the two. If this is
actually a real problem at all. I doubt move_native_irq() should be doing
work very often when it is called.

 -- Keir

> 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).