From: Andrew Jones <drjo...@redhat.com> We should only check current->sched_info.run_delay once when updating stolen time. Otherwise there's a chance there could be a change between checks that we miss (preemption disabling comes after vcpu request checks).
Signed-off-by: Andrew Jones <drjo...@redhat.com> Signed-off-by: Marc Zyngier <m...@kernel.org> Link: https://lore.kernel.org/r/20200804170604.42662-3-drjo...@redhat.com --- arch/arm64/kvm/pvtime.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/pvtime.c b/arch/arm64/kvm/pvtime.c index c3ef4ebd6846..95f9580275b1 100644 --- a/arch/arm64/kvm/pvtime.c +++ b/arch/arm64/kvm/pvtime.c @@ -13,6 +13,7 @@ void kvm_update_stolen_time(struct kvm_vcpu *vcpu) { struct kvm *kvm = vcpu->kvm; + u64 last_steal = vcpu->arch.steal.last_steal; u64 steal; __le64 steal_le; u64 offset; @@ -24,8 +25,8 @@ void kvm_update_stolen_time(struct kvm_vcpu *vcpu) /* Let's do the local bookkeeping */ steal = vcpu->arch.steal.steal; - steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal; - vcpu->arch.steal.last_steal = current->sched_info.run_delay; + vcpu->arch.steal.last_steal = READ_ONCE(current->sched_info.run_delay); + steal += vcpu->arch.steal.last_steal - last_steal; vcpu->arch.steal.steal = steal; steal_le = cpu_to_le64(steal); -- 2.27.0 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
