On Thu, Aug 19, 2021 at 11:43 AM Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > > On Mon, Aug 16, 2021 at 12:11:25AM +0000, Oliver Upton wrote: > > Sean noticed that KVM_GET_CLOCK was checking kvm_arch.use_master_clock > > outside of the pvclock sync lock. This is problematic, as the clock > > value written to the user may or may not actually correspond to a stable > > TSC. > > > > Fix the race by populating the entire kvm_clock_data structure behind > > the pvclock_gtod_sync_lock. > > Oliver, > > Can you please describe the race in more detail? > > Is it about host TSC going unstable VS parallel KVM_GET_CLOCK ? > Yeah, pretty much any event that causes us to set use_master_clock = false could interleave with the KVM_GET_CLOCK ioctl. A guest could kick its TSCs out of sync, for example, to cause this too. AFAICT, KVM serializes the write side (pvclock_update_vm_gtod_copy()) with pvclock_gtod_sync_lock, as it should. -- Thanks, Oliver
