On Wed, May 20, 2026, Ackerley Tng wrote: > Sean Christopherson <[email protected]> writes: > >> > } else { > >> > + /* > >> > + * Memory attributes cannot be obtained from guest_memfd > >> > while > >> > + * the MMU lock is held. > >> > + */ > >> > + if > >> > (KVM_BUG_ON(static_call_query(__kvm_get_memory_attributes) == > >> > + kvm_gmem_get_memory_attributes, kvm)) { > >> > + return 0; > >> > + } > >> > + > >> > >> This directly takes the address of kvm_gmem_get_memory_attributes, > >> which is only compiled if CONFIG_KVM_GUEST_MEMFD=y. This breaks > >> ARCH=i386. > > > > And this bleeds guest_memfd implementation details into places they don't > > belong. > > The right way to deal with this is to use lockdep_assert_not_held() in > > whatever > > code mustn't run with mmu_lock held. E.g. > > > > diff --git virt/kvm/guest_memfd.c virt/kvm/guest_memfd.c > > index c9f155c2dc5c..3bea9c1137ef 100644 > > --- virt/kvm/guest_memfd.c > > +++ virt/kvm/guest_memfd.c > > @@ -547,6 +547,9 @@ unsigned long kvm_gmem_get_memory_attributes(struct kvm > > *kvm, gfn_t gfn) > > struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn); > > struct inode *inode; > > > > + /* Comment goes here. */ > > + lockdep_assert_not_held(&kvm->mmu_lock); > > + > > /* > > * If this gfn has no associated memslot, there's no chance of the > > gfn > > * being backed by private memory, since guest_memfd must be used > > for > > > > But I'm confused, because kvm_gmem_get_memory_attributes() doesn't actually > > take > > filemap_invalidate_lock(), so what exactly is the problem? > > > > Ahh I can drop this patch now. kvm_gmem_get_memory_attributes() used to > take the filemap_invalidate_lock(), but after Liam pointed out that > the attributes maple tree should be using MT_FLAGS_USE_RCU, I stopped > taking filemap_invalidate_lock() and forgot to undo this. > > I'll wait a bit for more reviews and then put out another revision > without this patch.
If this is the only issue with v6, don't send a new version, I'll just drop it when applying.
