summaryrefslogtreecommitdiffstats
path: root/arch/x86
diff options
context:
space:
mode:
authorVitaly Kuznetsov <vkuznets@redhat.com>2020-06-10 19:55:31 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2020-06-11 12:35:19 -0400
commit7863e346e1089b40cac1c7d9098314c405e2e1e3 (patch)
treefa4c2c9d3b1d63d7d0ec19e60e02af9dcd7f477d /arch/x86
parentcd18eaeaffa6e5291cdbcd591334d577c4e897df (diff)
downloadlinux-7863e346e1089b40cac1c7d9098314c405e2e1e3.tar.gz
linux-7863e346e1089b40cac1c7d9098314c405e2e1e3.tar.bz2
linux-7863e346e1089b40cac1c7d9098314c405e2e1e3.zip
KVM: async_pf: Cleanup kvm_setup_async_pf()
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@redhat.com> Message-Id: <20200610175532.779793-1-vkuznets@redhat.com> Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/x86')
0 files changed, 0 insertions, 0 deletions