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
..
events
xen-pciback
xenbus
xenfs
acpi.c
balloon.c
biomerge.c
cpu_hotplug.c
dbgp.c
efi.c
evtchn.c
fallback.c
features.c
gntalloc.c
gntdev.c
grant-table.c
Kconfig
Makefile
manage.c
mcelog.c
pci.c
pcpu.c
platform-pci.c
preempt.c
privcmd.c
privcmd.h
swiotlb-xen.c
sys-hypervisor.c
time.c
tmem.c
xen-acpi-cpuhotplug.c
xen-acpi-memhotplug.c
xen-acpi-pad.c
xen-acpi-processor.c
xen-balloon.c
xen-scsiback.c
xen-selfballoon.c
xen-stub.c
xlate_mmu.c