From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0332A1BC46 for ; Wed, 4 Feb 2026 21:37:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770241039; cv=none; b=FNI/XpWHFTj6/anxdhDnkJbLm16mSG+m9ZFXn1gyqJqURWLHNsw39tIuP0WYUADa5hNLsd4KGTD7vGcFSM/KvL/aR5s6/fqcJFdKesxsWqaS+qZLJ/AMlqzabpEpxyKfi37osUFVYQBDEwdDdmColTRHY8kNeQDEfywloLAvqeM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770241039; c=relaxed/simple; bh=NoQk+WUwevTmhgi2vLUcHu/2l3Wad6kBnJ/+pThVYNM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=c5wnya9NIBEh3q2dFPiCDYw3UlewYNj7mACAFGF5UqRf9R0LQRacEccYA+f+cdC7R2hOqgvDm+iukVMH90NFJsWc7JmbxUMKweRL6hGGG660G/N0XE/uBXgGRwSk4CXl8tSCHY0T+W/ZnzNk5Z1ZYGs/b84UtIlr29byGwLWsOo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=wwODQMWO; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wwODQMWO" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-81d9b88caf2so243758b3a.1 for ; Wed, 04 Feb 2026 13:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770241038; x=1770845838; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=x42FsSrubrOBY2TJXIwfVaWLWCG2JiMLbWyLTkA5Cdk=; b=wwODQMWOJyHLU0oMBLB7/qchJ48TawLkFUuFlL+ffBJO3jmzMQ2vTw4TOI+S/3bN0p SQXsEe2D7D4KlngslqJvcNVchlXRWoJ5RkslHuquuJJHn1ggrBGTcLegSe1nEoHUUSA4 3RKZMiY1RrDMDwe2c7HwjkMGFapQYkOQ9+0ryvPzcb2I7mNLUH0kHkPxAXKX2ZCRyfrA TAHaxoxy3u8IuzAUMtyUSIc08G9PUCh5fQVmv4GIER8oWaLJaujZxrGbBnuOKKzv2Ka8 m08liX1GyYIvWfdRSVgL+ER75qk956k8Lim5nFc3asopAsrubXscWrhbEG8DutvbxtyQ VD8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770241038; x=1770845838; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x42FsSrubrOBY2TJXIwfVaWLWCG2JiMLbWyLTkA5Cdk=; b=iGMBYvz+H1hTsBIQKbncWJK52JUP/eKhgpxVINfhSg2m5Vu6+h7kRxTxM3M7fs5//S 717ApRg/ewl6DlqTL0blMemKS5KSH9/BHRyUVbIwRd4+k6nd00u1Etjew/opqQLB487B 7/Jql5zCcxt9wzgpg02OosZuAysMDkIgXiQLFo5/Yju7cGSvm1aSd+DxIGbUDI/Rtms3 MIY19Vr2opW+PW79MS3SCEIwYtU/JtuHbpGa9lqaj4hjUO4AnKwWOCOkxwpXpH+VDszD 1D38Lx6hAJ1zG9kDfPy6aVJPIO0Ubtmk2Pv2CjHcavKsTV6Z+g/dW1PaSZiRWm1LeE/H 2dvw== X-Forwarded-Encrypted: i=1; AJvYcCVPSOUoUr8OR5gR9ehv0G80Wke/FXc7Ed+xJq4I19uk9jpB09zj4faWssm2ctB8kVHXTYvb62ii/ZekAzM=@vger.kernel.org X-Gm-Message-State: AOJu0YzMVna8A4NhlQTVIk8AutkLmaql/FLoKdhzy1p4StWv2jOGuAMM hlLNtzIU51XYSBwNQKzokA5YE5Nlk0rlKalQEXvBMIX61KNCIjsrOmCF0pxMjb7z4Sgu4YkJg59 pMpI2JA== X-Received: from pfvx9.prod.google.com ([2002:a05:6a00:2709:b0:7b8:922c:725d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:1a90:b0:81f:852b:a925 with SMTP id d2e1a72fcca58-8241c19da84mr4061956b3a.1.1770241038322; Wed, 04 Feb 2026 13:37:18 -0800 (PST) Date: Wed, 4 Feb 2026 13:37:16 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <697d115a.050a0220.1d61ec.0004.GAE@google.com> <20260204170144.2904483-1-ackerleytng@google.com> Message-ID: Subject: Re: [PATCH] KVM: guest_memfd: Disable VMA merging with VM_DONTEXPAND From: Sean Christopherson To: Ackerley Tng Cc: syzbot+33a04338019ac7e43a44@syzkaller.appspotmail.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, syzkaller-bugs@googlegroups.com, david@kernel.org, michael.roth@amd.com, vannapurve@google.com, kartikey406@gmail.com Content-Type: text/plain; charset="us-ascii" On Wed, Feb 04, 2026, Ackerley Tng wrote: > Ackerley Tng writes: > > > #syz test: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next > > > > guest_memfd VMAs don't need to be merged, Why not? There are benefits to merging VMAs that have nothing to do with folios. E.g. map 1GiB of guest_memfd with 512*512 4KiB VMAs, and then it becomes quite desirable to merge all of those VMAs into one. Creating _hugepages_ doesn't add value, but that's not the same things as merging VMAs. > > especially now, since guest_memfd only supports PAGE_SIZE folios. > > > > Set VM_DONTEXPAND on guest_memfd VMAs. > > Local tests and syzbot agree that this fixes the issue identified. :) > > I would like to look into madvise(MADV_COLLAPSE) and uprobes triggering > mapping/folio collapsing before submitting a full patch series. > > David, Michael, Vishal, what do you think of the choice of setting > VM_DONTEXPAND to disable khugepaged? I'm not one of the above, but for me it feels very much like treating a symptom and not fixing the underlying cause. It seems like what KVM should do is not block one path that triggers hugepage processing, but instead flat out disallow creating hugepages. Unfortunately, AFAICT, there's no existing way to prevent madvise() from clearing VM_NOHUGEPAGE, so we can't simply force that flag. I'd prefer not to special case guest_memfd, a la devdax, but I also want to address this head-on, not by removing a tangentially related trigger. > + For 4K guest_memfd, there's really nothing to expand > + For THP and HugeTLB guest_memfd (future), we actually don't want > expansion of the VMAs. > > IIUC setting VM_DONTEXPAND doesn't affect mremap() as long as the > remapping does not involve expansion. > > > In addition, this disables khugepaged from operating on guest_memfd folios, > > which may result in unintended merging of guest_memfd folios. > > > > Change-Id: I5867edcb66b075b54b25260afd22a198aee76df1 > > Signed-off-by: Ackerley Tng > > --- > > virt/kvm/guest_memfd.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > index fdaea3422c30..3d4ac461c28b 100644 > > --- a/virt/kvm/guest_memfd.c > > +++ b/virt/kvm/guest_memfd.c > > @@ -480,6 +480,12 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma) > > return -EINVAL; > > } > > > > + /* > > + * Disable VMA merging - guest_memfd VMAs should be > > + * static. This also stops khugepaged from operating on > > + * guest_memfd VMAs and folios. > > + */ > > + vm_flags_set(vma, VM_DONTEXPAND); > > vma->vm_ops = &kvm_gmem_vm_ops; > > > > return 0; > > -- > > 2.53.0.rc2.204.g2597b5adb4-goog