diff options
author | Sean Christopherson <seanjc@google.com> | 2023-10-27 11:21:53 -0700 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2023-11-13 05:31:38 -0500 |
commit | 193bbfaacc84f9ee9c281ec0a8dd2ec8e4821e57 (patch) | |
tree | 70a9a8676dbb7bdfc2909c6a4db3b223d1c09313 /COPYING | |
parent | cec29eef0a815386d520d61c2cbe16d537931639 (diff) | |
download | linux-stable-193bbfaacc84f9ee9c281ec0a8dd2ec8e4821e57.tar.gz linux-stable-193bbfaacc84f9ee9c281ec0a8dd2ec8e4821e57.tar.bz2 linux-stable-193bbfaacc84f9ee9c281ec0a8dd2ec8e4821e57.zip |
KVM: Drop .on_unlock() mmu_notifier hook
Drop the .on_unlock() mmu_notifer hook now that it's no longer used for
notifying arch code that memory has been reclaimed. Adding .on_unlock()
and invoking it *after* dropping mmu_lock was a terrible idea, as doing so
resulted in .on_lock() and .on_unlock() having divergent and asymmetric
behavior, and set future developers up for failure, i.e. all but asked for
bugs where KVM relied on using .on_unlock() to try to run a callback while
holding mmu_lock.
Opportunistically add a lockdep assertion in kvm_mmu_invalidate_end() to
guard against future bugs of this nature.
Reported-by: Isaku Yamahata <isaku.yamahata@intel.com>
Link: https://lore.kernel.org/all/20230802203119.GB2021422@ls.amr.corp.intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Message-Id: <20231027182217.3615211-12-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions