Boris Ostrovsky ff1e22e7a6 xen/events: Mask a moving irq
Moving an unmasked irq may result in irq handler being invoked on both
source and target CPUs.

With 2-level this can happen as follows:

On source CPU:
        evtchn_2l_handle_events() ->
            generic_handle_irq() ->
                handle_edge_irq() ->
                   eoi_pirq():
                       irq_move_irq(data);

                       /***** WE ARE HERE *****/

                       if (VALID_EVTCHN(evtchn))
                           clear_evtchn(evtchn);

If at this moment target processor is handling an unrelated event in
evtchn_2l_handle_events()'s loop it may pick up our event since target's
cpu_evtchn_mask claims that this event belongs to it *and* the event is
unmasked and still pending. At the same time, source CPU will continue
executing its own handle_edge_irq().

With FIFO interrupt the scenario is similar: irq_move_irq() may result
in a EVTCHNOP_unmask hypercall which, in turn, may make the event
pending on the target CPU.

We can avoid this situation by moving and clearing the event while
keeping event masked.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
2016-04-04 11:18:00 +01:00
..
2016-03-21 13:14:16 -07:00
2016-03-24 23:13:48 -07:00
2016-03-16 08:36:55 -07:00
2016-03-25 08:52:25 -07:00
2016-03-22 15:36:02 -07:00
2016-03-18 10:15:11 -07:00
2016-03-17 13:47:50 -07:00
2016-03-20 15:40:32 -07:00
2016-03-18 10:15:11 -07:00
2016-03-22 11:57:43 -07:00
2016-03-23 17:20:59 -07:00
2016-03-24 19:57:15 -07:00
2016-03-18 10:15:11 -07:00
2016-03-21 14:35:52 -07:00
2016-03-24 19:57:15 -07:00
2016-03-24 23:13:48 -07:00
2016-03-19 15:15:07 -07:00
2016-03-23 17:20:59 -07:00
2016-03-18 10:15:11 -07:00
2016-03-24 22:49:08 -07:00
2016-03-26 11:31:01 -07:00
2016-03-20 15:40:32 -07:00
2016-03-17 12:34:54 -07:00
2016-03-22 12:55:17 -07:00
2016-03-17 13:05:09 -07:00
2016-04-04 11:18:00 +01:00