Message ID | 1620634919-4563-1-git-send-email-wanpengli@tencent.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | KVM: x86: hyper-v: Task srcu lock when accessing kvm_memslots() | expand |
Wanpeng Li <kernellwp@gmail.com> writes: > From: Wanpeng Li <wanpengli@tencent.com> > > WARNING: suspicious RCU usage > 5.13.0-rc1 #4 Not tainted > ----------------------------- > ./include/linux/kvm_host.h:710 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > rcu_scheduler_active = 2, debug_locks = 1 > 1 lock held by hyperv_clock/8318: > #0: ffffb6b8cb05a7d8 (&hv->hv_lock){+.+.}-{3:3}, at: kvm_hv_invalidate_tsc_page+0x3e/0xa0 [kvm] > > stack backtrace: > CPU: 3 PID: 8318 Comm: hyperv_clock Not tainted 5.13.0-rc1 #4 > Call Trace: > dump_stack+0x87/0xb7 > lockdep_rcu_suspicious+0xce/0xf0 > kvm_write_guest_page+0x1c1/0x1d0 [kvm] > kvm_write_guest+0x50/0x90 [kvm] > kvm_hv_invalidate_tsc_page+0x79/0xa0 [kvm] > kvm_gen_update_masterclock+0x1d/0x110 [kvm] > kvm_arch_vm_ioctl+0x2a7/0xc50 [kvm] > kvm_vm_ioctl+0x123/0x11d0 [kvm] > __x64_sys_ioctl+0x3ed/0x9d0 > do_syscall_64+0x3d/0x80 > entry_SYSCALL_64_after_hwframe+0x44/0xae > > kvm_memslots() will be called by kvm_write_guest(), so we should take the srcu lock. > > Fixes: e880c6ea5 (KVM: x86: hyper-v: Prevent using not-yet-updated TSC page by secondary CPUs) > Signed-off-by: Wanpeng Li <wanpengli@tencent.com> > --- > arch/x86/kvm/hyperv.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > index f98370a3..f00830e 100644 > --- a/arch/x86/kvm/hyperv.c > +++ b/arch/x86/kvm/hyperv.c > @@ -1172,6 +1172,7 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) > { > struct kvm_hv *hv = to_kvm_hv(kvm); > u64 gfn; > + int idx; > > if (hv->hv_tsc_page_status == HV_TSC_PAGE_BROKEN || > hv->hv_tsc_page_status == HV_TSC_PAGE_UNSET || > @@ -1190,9 +1191,16 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) > gfn = hv->hv_tsc_page >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT; > > hv->tsc_ref.tsc_sequence = 0; > + > + /* > + * Take the srcu lock as memslots will be accessed to check the gfn > + * cache generation against the memslots generation. > + */ > + idx = srcu_read_lock(&kvm->srcu); > if (kvm_write_guest(kvm, gfn_to_gpa(gfn), > &hv->tsc_ref, sizeof(hv->tsc_ref.tsc_sequence))) > hv->hv_tsc_page_status = HV_TSC_PAGE_BROKEN; > + srcu_read_unlock(&kvm->srcu, idx); > > out_unlock: > mutex_unlock(&hv->hv_lock); Thanks! Do we need to do the same in kvm_hv_setup_tsc_page()?
On Mon, 10 May 2021 at 16:48, Vitaly Kuznetsov <vkuznets@redhat.com> wrote: > > Wanpeng Li <kernellwp@gmail.com> writes: > > > From: Wanpeng Li <wanpengli@tencent.com> > > > > WARNING: suspicious RCU usage > > 5.13.0-rc1 #4 Not tainted > > ----------------------------- > > ./include/linux/kvm_host.h:710 suspicious rcu_dereference_check() usage! > > > > other info that might help us debug this: > > > > rcu_scheduler_active = 2, debug_locks = 1 > > 1 lock held by hyperv_clock/8318: > > #0: ffffb6b8cb05a7d8 (&hv->hv_lock){+.+.}-{3:3}, at: kvm_hv_invalidate_tsc_page+0x3e/0xa0 [kvm] > > > > stack backtrace: > > CPU: 3 PID: 8318 Comm: hyperv_clock Not tainted 5.13.0-rc1 #4 > > Call Trace: > > dump_stack+0x87/0xb7 > > lockdep_rcu_suspicious+0xce/0xf0 > > kvm_write_guest_page+0x1c1/0x1d0 [kvm] > > kvm_write_guest+0x50/0x90 [kvm] > > kvm_hv_invalidate_tsc_page+0x79/0xa0 [kvm] > > kvm_gen_update_masterclock+0x1d/0x110 [kvm] > > kvm_arch_vm_ioctl+0x2a7/0xc50 [kvm] > > kvm_vm_ioctl+0x123/0x11d0 [kvm] > > __x64_sys_ioctl+0x3ed/0x9d0 > > do_syscall_64+0x3d/0x80 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > kvm_memslots() will be called by kvm_write_guest(), so we should take the srcu lock. > > > > Fixes: e880c6ea5 (KVM: x86: hyper-v: Prevent using not-yet-updated TSC page by secondary CPUs) > > Signed-off-by: Wanpeng Li <wanpengli@tencent.com> > > --- > > arch/x86/kvm/hyperv.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c > > index f98370a3..f00830e 100644 > > --- a/arch/x86/kvm/hyperv.c > > +++ b/arch/x86/kvm/hyperv.c > > @@ -1172,6 +1172,7 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) > > { > > struct kvm_hv *hv = to_kvm_hv(kvm); > > u64 gfn; > > + int idx; > > > > if (hv->hv_tsc_page_status == HV_TSC_PAGE_BROKEN || > > hv->hv_tsc_page_status == HV_TSC_PAGE_UNSET || > > @@ -1190,9 +1191,16 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) > > gfn = hv->hv_tsc_page >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT; > > > > hv->tsc_ref.tsc_sequence = 0; > > + > > + /* > > + * Take the srcu lock as memslots will be accessed to check the gfn > > + * cache generation against the memslots generation. > > + */ > > + idx = srcu_read_lock(&kvm->srcu); > > if (kvm_write_guest(kvm, gfn_to_gpa(gfn), > > &hv->tsc_ref, sizeof(hv->tsc_ref.tsc_sequence))) > > hv->hv_tsc_page_status = HV_TSC_PAGE_BROKEN; > > + srcu_read_unlock(&kvm->srcu, idx); > > > > out_unlock: > > mutex_unlock(&hv->hv_lock); > > Thanks! > > Do we need to do the same in kvm_hv_setup_tsc_page()? kvm_hv_setup_tsc_page() is called in vcpu_enter_guest() path which has already held kvm->srcu lock. Wanpeng
Wanpeng Li <kernellwp@gmail.com> writes: > On Mon, 10 May 2021 at 16:48, Vitaly Kuznetsov <vkuznets@redhat.com> wrote: >> >> Wanpeng Li <kernellwp@gmail.com> writes: >> >> > From: Wanpeng Li <wanpengli@tencent.com> >> > >> > WARNING: suspicious RCU usage >> > 5.13.0-rc1 #4 Not tainted >> > ----------------------------- >> > ./include/linux/kvm_host.h:710 suspicious rcu_dereference_check() usage! >> > >> > other info that might help us debug this: >> > >> > rcu_scheduler_active = 2, debug_locks = 1 >> > 1 lock held by hyperv_clock/8318: >> > #0: ffffb6b8cb05a7d8 (&hv->hv_lock){+.+.}-{3:3}, at: kvm_hv_invalidate_tsc_page+0x3e/0xa0 [kvm] >> > >> > stack backtrace: >> > CPU: 3 PID: 8318 Comm: hyperv_clock Not tainted 5.13.0-rc1 #4 >> > Call Trace: >> > dump_stack+0x87/0xb7 >> > lockdep_rcu_suspicious+0xce/0xf0 >> > kvm_write_guest_page+0x1c1/0x1d0 [kvm] >> > kvm_write_guest+0x50/0x90 [kvm] >> > kvm_hv_invalidate_tsc_page+0x79/0xa0 [kvm] >> > kvm_gen_update_masterclock+0x1d/0x110 [kvm] >> > kvm_arch_vm_ioctl+0x2a7/0xc50 [kvm] >> > kvm_vm_ioctl+0x123/0x11d0 [kvm] >> > __x64_sys_ioctl+0x3ed/0x9d0 >> > do_syscall_64+0x3d/0x80 >> > entry_SYSCALL_64_after_hwframe+0x44/0xae >> > >> > kvm_memslots() will be called by kvm_write_guest(), so we should take the srcu lock. >> > >> > Fixes: e880c6ea5 (KVM: x86: hyper-v: Prevent using not-yet-updated TSC page by secondary CPUs) >> > Signed-off-by: Wanpeng Li <wanpengli@tencent.com> >> > --- >> > arch/x86/kvm/hyperv.c | 8 ++++++++ >> > 1 file changed, 8 insertions(+) >> > >> > diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c >> > index f98370a3..f00830e 100644 >> > --- a/arch/x86/kvm/hyperv.c >> > +++ b/arch/x86/kvm/hyperv.c >> > @@ -1172,6 +1172,7 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) >> > { >> > struct kvm_hv *hv = to_kvm_hv(kvm); >> > u64 gfn; >> > + int idx; >> > >> > if (hv->hv_tsc_page_status == HV_TSC_PAGE_BROKEN || >> > hv->hv_tsc_page_status == HV_TSC_PAGE_UNSET || >> > @@ -1190,9 +1191,16 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) >> > gfn = hv->hv_tsc_page >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT; >> > >> > hv->tsc_ref.tsc_sequence = 0; >> > + >> > + /* >> > + * Take the srcu lock as memslots will be accessed to check the gfn >> > + * cache generation against the memslots generation. >> > + */ >> > + idx = srcu_read_lock(&kvm->srcu); >> > if (kvm_write_guest(kvm, gfn_to_gpa(gfn), >> > &hv->tsc_ref, sizeof(hv->tsc_ref.tsc_sequence))) >> > hv->hv_tsc_page_status = HV_TSC_PAGE_BROKEN; >> > + srcu_read_unlock(&kvm->srcu, idx); >> > >> > out_unlock: >> > mutex_unlock(&hv->hv_lock); >> >> Thanks! >> >> Do we need to do the same in kvm_hv_setup_tsc_page()? > > kvm_hv_setup_tsc_page() is called in vcpu_enter_guest() path which has > already held kvm->srcu lock. > I, true, thanks for checking! For the patch: Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c index f98370a3..f00830e 100644 --- a/arch/x86/kvm/hyperv.c +++ b/arch/x86/kvm/hyperv.c @@ -1172,6 +1172,7 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) { struct kvm_hv *hv = to_kvm_hv(kvm); u64 gfn; + int idx; if (hv->hv_tsc_page_status == HV_TSC_PAGE_BROKEN || hv->hv_tsc_page_status == HV_TSC_PAGE_UNSET || @@ -1190,9 +1191,16 @@ void kvm_hv_invalidate_tsc_page(struct kvm *kvm) gfn = hv->hv_tsc_page >> HV_X64_MSR_TSC_REFERENCE_ADDRESS_SHIFT; hv->tsc_ref.tsc_sequence = 0; + + /* + * Take the srcu lock as memslots will be accessed to check the gfn + * cache generation against the memslots generation. + */ + idx = srcu_read_lock(&kvm->srcu); if (kvm_write_guest(kvm, gfn_to_gpa(gfn), &hv->tsc_ref, sizeof(hv->tsc_ref.tsc_sequence))) hv->hv_tsc_page_status = HV_TSC_PAGE_BROKEN; + srcu_read_unlock(&kvm->srcu, idx); out_unlock: mutex_unlock(&hv->hv_lock);