On Tue, Nov 04, 2025 at 09:57:26AM -0800, Sean Christopherson wrote:
> On Thu, Oct 30, 2025, Yan Zhao wrote:
> > On Wed, Oct 22, 2025 at 12:53:53PM +0800, Yan Zhao wrote:
> > > On Thu, Oct 16, 2025 at 05:32:22PM -0700, Sean Christopherson wrote:
> > > > Link:
> > > > https://lore.kernel.org/all/[email protected]
> > >
> > > Hi Sean,
> > >
> > >
> > > Will you post [1] to fix the AB-BA deadlock issue for huge page in-place
> > > conversion as well?
>
> If you (or anyone) has the bandwidth, please pick it up. I won't have cycles
> to
> look at that for many weeks (potentially not even this calendar year).
Got it!
On the other hand, do you think we can address the warning as below?
The code is based on [2].
@@ -853,6 +859,10 @@ static int kvm_gmem_init_inode(struct inode *inode, loff_t
size, u64 flags)
inode->i_size = size;
mapping_set_gfp_mask(inode->i_mapping, GFP_HIGHUSER);
mapping_set_inaccessible(inode->i_mapping);
+ if (flags &GUEST_MEMFD_FLAG_MMAP)
+
lockdep_set_class_and_subclass(&inode->i_mapping->invalidate_lock,
+
&inode->i_sb->s_type->invalidate_lock_key, 1);
+
/* Unmovable mappings are supposed to be marked unevictable as well. */
WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
As noted in [3], the only scenario can trigger the warning after [2] is when a
process creates a TDX VM with non-in-place-conversion guest_memfd and a normal
VM with in-place-conversion guest_memfd. The two invalidate_lock's don't contend
with each other theoretically.
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/aqmi%[email protected]/
