diff options
author | Vitaly Kuznetsov <vkuznets@redhat.com> | 2020-06-10 19:55:31 +0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2020-06-11 12:35:19 -0400 |
commit | 7863e346e1089b40cac1c7d9098314c405e2e1e3 (patch) | |
tree | fa4c2c9d3b1d63d7d0ec19e60e02af9dcd7f477d /arch/x86 | |
parent | cd18eaeaffa6e5291cdbcd591334d577c4e897df (diff) | |
download | linux-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