lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 10 Jun 2020 11:14:53 -0700 From: Sean Christopherson <sean.j.christopherson@...el.com> To: Vitaly Kuznetsov <vkuznets@...hat.com> Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>, Wanpeng Li <wanpengli@...cent.com>, Jim Mattson <jmattson@...gle.com>, Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/2] KVM: async_pf: Cleanup kvm_setup_async_pf() On Wed, Jun 10, 2020 at 07:55:31PM +0200, Vitaly Kuznetsov wrote: > schedule_work() returns 'false' only when the work is already on the queue > and this can't happen as kvm_setup_async_pf() always allocates a new one. > Also, to avoid potential race, it makes sense to to schedule_work() at the > very end after we've added it to the queue. > > While on it, do some minor cleanup. gfn_to_pfn_async() mentioned in a > comment does not currently exist and, moreover, we can check > kvm_is_error_hva() at the very beginning, before we try to allocate work so > 'retry_sync' label can go away completely. > > Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com> > --- > virt/kvm/async_pf.c | 19 ++++++------------- > 1 file changed, 6 insertions(+), 13 deletions(-) > > diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c > index f1e07fae84e9..ba080088da76 100644 > --- a/virt/kvm/async_pf.c > +++ b/virt/kvm/async_pf.c > @@ -164,7 +164,9 @@ int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, > if (vcpu->async_pf.queued >= ASYNC_PF_PER_VCPU) > return 0; > > - /* setup delayed work */ > + /* Arch specific code should not do async PF in this case */ > + if (unlikely(kvm_is_error_hva(hva))) This feels like it should be changed to a WARN_ON_ONCE in a follow-up. With the WARN, the comment could probably be dropped. I'd also be in favor of changing the return type to a boolean. I think you alluded to it earlier, the current semantics are quite confusing as they invert the normal "return 0 on success". For this patch: Reviewed-by: Sean Christopherson <sean.j.christopherson@...el.com>
Powered by blists - more mailing lists