On Sun, Dec 5, 2021 at 10:55 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 12/5/21 14:30, kernel test robot wrote: > > > > Chain exists of: > > fs_reclaim --> mmu_notifier_invalidate_range_start --> &(kvm)->mmu_lock > > > > Possible unsafe locking scenario: > > > > CPU0 CPU1 > > ---- ---- > > lock(&(kvm)->mmu_lock); > > lock(mmu_notifier_invalidate_range_start); > > lock(&(kvm)->mmu_lock); > > lock(fs_reclaim); > > > > David, this is yours; basically, kvm_mmu_topup_memory_cache must be > called outside the mmu_lock. Ah, I see. kvm_arch_mmu_enable_log_dirty_pt_masked is called with mmu_lock already held. I'll make sure to address this in v1. In theory this should just go away when I switch away from using split_caches to Sean's suggestion of allocating under the mmu_lock with reclaim disabled.
