From: Jeremy Fitzhardinge Date: Mon, 26 May 2008 22:31:05 +0000 (+0100) Subject: xen: don't worry about preempt during xen_irq_enable() X-Git-Tag: firefly_0821_release~19697^2~253^24~40 X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=239d1fc04ed0b58d638096b12a7f6d50269d30c9;p=firefly-linux-kernel-4.4.55.git xen: don't worry about preempt during xen_irq_enable() When enabling interrupts, we don't need to worry about preemption, because we either enter with interrupts disabled - so no preemption - or the caller is confused and is re-enabling interrupts on some indeterminate processor. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Thomas Gleixner --- diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index f6876485ee7d..4a372b71239d 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -235,13 +235,13 @@ static void xen_irq_enable(void) { struct vcpu_info *vcpu; - /* There's a one instruction preempt window here. We need to - make sure we're don't switch CPUs between getting the vcpu - pointer and updating the mask. */ - preempt_disable(); + /* We don't need to worry about being preempted here, since + either a) interrupts are disabled, so no preemption, or b) + the caller is confused and is trying to re-enable interrupts + on an indeterminate processor. */ + vcpu = x86_read_percpu(xen_vcpu); vcpu->evtchn_upcall_mask = 0; - preempt_enable_no_resched(); /* Doesn't matter if we get preempted here, because any pending event will get dealt with anyway. */