mirror of
https://github.com/xen-project/xen.git
synced 2026-10-29 10:40:03 +01:00
Two cpus entering evtchn_fifo_set_pending() for the same event channel can race in case the first one gets interrupted after setting EVTCHN_FIFO_PENDING and when the other one manages to set EVTCHN_FIFO_LINKED before the first one is testing that bit. This can lead to evtchn_check_pollers() being called before the event is put properly into the queue, resulting eventually in the guest not seeing the event pending and thus blocking forever afterwards. Note that commit5f2df45ead("xen/evtchn: rework per event channel lock") made the race just more obvious, while the fifo event channel implementation had this race forever since the introduction and use of per-channel locks, when an unmask operation was running in parallel with an event channel send operation. Using a spinlock for the per event channel lock had turned out problematic due to some paths needing to take the lock are called with interrupts off, so the lock would need to disable interrupts, which in turn broke some use cases related to vm events. For avoiding this race the queue locking in evtchn_fifo_set_pending() needs to be reworked to cover the test of EVTCHN_FIFO_PENDING, EVTCHN_FIFO_MASKED and EVTCHN_FIFO_LINKED, too. Additionally when an event channel needs to change queues both queues need to be locked initially, in order to avoid having a window with no lock held at all. Reported-by: Jan Beulich <jbeulich@suse.com> Fixes:5f2df45ead("xen/evtchn: rework per event channel lock") Fixes:de6acb78bf("evtchn: use a per-event channel lock for sending events") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> master commit:71ac522909master date: 2020-11-30 14:05:39 +0100