summaryrefslogtreecommitdiffstats
path: root/COPYING
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2023-10-27 11:21:53 -0700
committerPaolo Bonzini <pbonzini@redhat.com>2023-11-13 05:31:38 -0500
commit193bbfaacc84f9ee9c281ec0a8dd2ec8e4821e57 (patch)
tree70a9a8676dbb7bdfc2909c6a4db3b223d1c09313 /COPYING
parentcec29eef0a815386d520d61c2cbe16d537931639 (diff)
downloadlinux-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