* Patch "KVM: arm/arm64: Fix occasional warning from the timer work function" has been added to the 4.9-stable tree
@ 2017-12-06 16:59 gregkh
0 siblings, 0 replies; only message in thread
From: gregkh @ 2017-12-06 16:59 UTC (permalink / raw)
To: christoffer.dall, alexander.levin, gregkh, marc.zyngier, mbrugger
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Fix occasional warning from the timer work function
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Wed Dec 6 17:39:55 CET 2017
From: Christoffer Dall <christoffer.dall@linaro.org>
Date: Mon, 9 Jan 2017 12:18:56 +0100
Subject: KVM: arm/arm64: Fix occasional warning from the timer work function
From: Christoffer Dall <christoffer.dall@linaro.org>
[ Upstream commit 63e41226afc3f7a044b70325566fa86ac3142538 ]
When a VCPU blocks (WFI) and has programmed the vtimer, we program a
soft timer to expire in the future to wake up the vcpu thread when
appropriate. Because such as wake up involves a vcpu kick, and the
timer expire function can get called from interrupt context, and the
kick may sleep, we have to schedule the kick in the work function.
The work function currently has a warning that gets raised if it turns
out that the timer shouldn't fire when it's run, which was added because
the idea was that in that case the work should never have been cancelled.
However, it turns out that this whole thing is racy and we can get
spurious warnings. The problem is that we clear the armed flag in the
work function, which may run in parallel with the
kvm_timer_unschedule->timer_disarm() call. This results in a possible
situation where the timer_disarm() call does not call
cancel_work_sync(), which effectively synchronizes the completion of the
work function with running the VCPU. As a result, the VCPU thread
proceeds before the work function completees, causing changes to the
timer state such that kvm_timer_should_fire(vcpu) returns false in the
work function.
All we do in the work function is to kick the VCPU, and an occasional
rare extra kick never harmed anyone. Since the race above is extremely
rare, we don't bother checking if the race happens but simply remove the
check and the clearing of the armed flag from the work function.
Reported-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/arm/arch_timer.c | 3 ---
1 file changed, 3 deletions(-)
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -89,9 +89,6 @@ static void kvm_timer_inject_irq_work(st
struct kvm_vcpu *vcpu;
vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
- vcpu->arch.timer_cpu.armed = false;
-
- WARN_ON(!kvm_timer_should_fire(vcpu));
/*
* If the vcpu is blocked we want to wake it up so that it will see
Patches currently in stable-queue which might be from christoffer.dall@linaro.org are
queue-4.9/kvm-arm-arm64-fix-occasional-warning-from-the-timer-work-function.patch
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2017-12-06 17:00 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-06 16:59 Patch "KVM: arm/arm64: Fix occasional warning from the timer work function" has been added to the 4.9-stable tree gregkh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).