diff options
author | Sean Christopherson <seanjc@google.com> | 2024-04-23 22:16:49 +0300 |
---|---|---|
committer | Sean Christopherson <seanjc@google.com> | 2024-06-03 18:55:55 +0300 |
commit | 778c350eb580a497c9da2a01e314fe12674cb66a (patch) | |
tree | c918315eeefabed11c0b3c1843cf070f882f95de /tools/perf/scripts/python/exported-sql-viewer.py | |
parent | f8aadead19713c610c175a8d416bca6175e5840e (diff) | |
download | linux-778c350eb580a497c9da2a01e314fe12674cb66a.tar.xz |
Revert "KVM: async_pf: avoid recursive flushing of work items"
Now that KVM does NOT gift async #PF workers a "struct kvm" reference,
don't bother skipping "done" workers when flushing/canceling queued
workers, as the deadlock that was being fudged around can no longer occur.
When workers, i.e. async_pf_execute(), were gifted a referenced, it was
possible for a worker to put the last reference and trigger VM destruction,
i.e. trigger flushing of a workqueue from a worker in said workqueue.
Note, there is no actual lock, the deadlock was that a worker will be
stuck waiting for itself (the workqueue code simulates a lock/unlock via
lock_map_{acquire,release}()).
Skipping "done" workers isn't problematic per se, but using work->vcpu as
a "done" flag is confusing, e.g. it's not clear that async_pf.lock is
acquired to protect the work->vcpu, NOT the processing of async_pf.queue
(which is protected by vcpu->mutex).
This reverts commit 22583f0d9c85e60c9860bc8a0ebff59fe08be6d7.
Suggested-by: Xu Yilun <yilun.xu@linux.intel.com>
Link: https://lore.kernel.org/r/20240423191649.2885257-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions