forked from luck/tmp_suning_uos_patched
ff1e22e7a6
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> |
||
---|---|---|
.. | ||
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 |